| Type | Wish | Status | submitted | Date | 30-Mar-2015 09:20 |
|---|---|---|---|---|---|
| Version | r3 master | Category | Unspecified | Submitted by | fork |
| Platform | All | Severity | minor | Priority | high |
| Summary | Rename MOLD to take the name SOURCE, use more general ?? if needed |
|---|---|
| Description |
The function known as SOURCE is currently a console-oriented function. It basically takes a quoted lit-word or path, looks it up, and puts that word in front of the molded value: >> probe :source make function! [[ "Prints the source code for a word." 'word [word! path!] ][ if not value? word [print [word "undefined"] exit] print head insert mold get word reduce [word ": "] exit ]] The quoting makes it virtually useless outside the console. You cannot call it on a FUNCTION!, because it doesn't know its name. It prints its output, and is hence almost certainly unused anywhere besides the console. The word is too valuable to take for the console command SOURCE when MOLD is such a terrible and off-putting name. SOURCE is a perfect name for what MOLD does. The ?? function already exists to throw a set-word in front of what something is: >> ?? source source: make function! [[ "Prints the source code for a word." 'word [word! path!] ][ if not value? word [print [word "undefined"] exit] print head insert mold get word reduce [word ": "] exit ]] So the behavior is duplicated already. As SOURCE is a console-oriented function with PRINT-only output, its entrenchment in existing code is likely negligible...only by habit. Console users typing SOURCE on a function and getting the output returned as a string might well not notice the difference, in output; the only difference being to remember to use a GET-WORD!: >> mold :source ;-- but imagine this said source :source == {make function! [[ "Prints the source code for a word." 'word [word! path!] ][ if not value? word [print [word "undefined"] exit] print head insert mold get word reduce [word ": "] exit ]]} New users will not notice the oldy moldy word MOLD, because it will not be in examples, and that will be good. Nevertheless, MOLD could be retained in R2/Backward along with all the other stuff you shouldn't use because there's better (e.g. still using FORM instead of the corrected TO-STRING). What's not to love about this one? |
| Example code |
| Assigned to | n/a | Fixed in | - | Last Update | 31-Mar-2015 05:20 |
|---|
| Comments | |
|---|---|
|
(0004621)
adrians 31-Mar-2015 02:45 |
If there's to be a distinction between what we call the source as entered by the user and the definitive, or canonical interpretation of that source by the runtime, then source and mold (or a better word) should have different meanings, IMO. If we don't care about maintaining that distinction, then sure, source is a nicer word than mold. |
|
(0004622)
fork 31-Mar-2015 03:24 |
One thing to notice about "old SOURCE" is that it doesn't return you a make-spec...it just printed some stuff out. One reason it didn't give you a value back is because it would have to put that in a block to aggregate. So if your SOURCE tried to give back a value that *wasn't* a string it would be like:
[make function! [a b] [foo a + b]] Hence so SPEC-OF and BODY-OF really are probably the best primitives, and the best way to think of the values you are trying to give names to. I'm not opposed to someone writing MAKE-SPEC-OF and returning that block if they really wanted it. But it certainly has no special status claim on being "the source". In a system hurting for a good name to replace MOLD, I'm pretty convinced SOURCE is it. The existing SOURCE is a waste of the word and cannot really be salvaged as anything other than a console command. OTOH under Plan Minus Four: >> source :foo == "function![[a b] [foo a + b]" I'd be fine with that being the go-to for getting source, even with the colon. It looks fine, shows me what I'm looking for. And can be used in code as well as in the console. If we are to get technical about what the "canonical interpretation of the source is by the runtime", then you need something a-la RebBin/RedBin to get that. (SOURCE/BINARY?) The canonical interpretation of the source by the runtime has bindings and references to memory nodes in it. |
|
(0004623)
abolka 31-Mar-2015 04:46 |
At first glance, SOURCE doesn't strike me to be particularly evocative of the proposed purpose. It's also such a widely used term, that SOURCE simply doesn't strike me as specific enough (also think about inflected use in jargon, such as "the sourced value" or "then I sourced it out"). Further, the verbing strikes me at rather awkward (and something that we otherwise try to avoid), but that could be ameliorated with the suggested SOURCE-OF. Finally, I think Adrian's point is a good one -- is there (should there be?) a difference between between a code/data-pretty printer that aims to reproduce something as close to what the original source was as possible (along the lines of heeding NEW-LINE), and an exchange-oriented serialiser?
I'll give it some more thought, but I think we should be able to do better than that. SOURCE is not it, sorry. |
|
(0004626)
Gregg 31-Mar-2015 05:18 |
Maybe I'm missing something, but why not just have SOURCE return the formatted string. If whatever console doesn't display it fully, they can add PRINT themselves, or another shortcut for that will be proposed. |
|
(0004627)
Gregg 31-Mar-2015 05:20 |
Renaming MOLD, for me, expands into much larger issues, where we want a matrix of needs and solutions for conversions. Like the *JOIN funcs, the various options we have overlap, along with the loading side, in sometimes unclear ways. |
| Date | User | Field | Action | Change |
|---|---|---|---|---|
| 31-Mar-2015 05:20 | Gregg | Comment : 0004627 | Added | - |
| 31-Mar-2015 05:18 | Gregg | Comment : 0004626 | Added | - |
| 31-Mar-2015 04:46 | abolka | Comment : 0004623 | Added | - |
| 31-Mar-2015 03:31 | Fork | Comment : 0004622 | Modified | - |
| 31-Mar-2015 03:30 | Fork | Comment : 0004622 | Modified | - |
| 31-Mar-2015 03:26 | Fork | Comment : 0004622 | Modified | - |
| 31-Mar-2015 03:24 | Fork | Comment : 0004622 | Added | - |
| 31-Mar-2015 02:45 | adrians | Comment : 0004621 | Added | - |
| 30-Mar-2015 09:53 | Fork | Description | Modified | - |
| 30-Mar-2015 09:29 | Fork | Description | Modified | - |
| 30-Mar-2015 09:27 | Fork | Description | Modified | - |
| 30-Mar-2015 09:20 | Fork | Ticket | Added | - |