Rename MOLD to take the name SOURCE, use more general ?? if needed

[rebolbot]

Submitted by: fork

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?

^{CC - Data [ Version: r3 master Type: Wish Platform: All Category: Unspecified Reproduce: Always Fixed-in:none ]}

[rebolbot]

Submitted by: adrians

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.

[rebolbot]

Submitted by: fork

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.

[rebolbot]

Submitted by: abolka

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.

[rebolbot]

Submitted by: Gregg

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.

[rebolbot]

Submitted by: Gregg

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.

[hostilefork]

:facepunch: Should be dismissed. :facepunch:

The question of if SOURCE is good or bad notwithstanding (its noun-ness seems to make people want it to be a variable name, if anything), Ren-C's current answer is to make TO-STRING have the basic behavior of MOLD...with MOLD retained as a short synonym for expert usage. MOLD would then be avoided in examples given to inexperienced readers, due to its appearance.

The SPELLING-OF operation helps specifically when a word is to be converted to a string without its decoration (a behavior that changed between Rebol2 and R3-Alpha w.r.t. string conversions)

Main concern in terms of change in behavior is TO-STRING of BINARY!, which previously would interpret the binary as UTF-8 to make a string (as opposed to the MOLD behavior which would be to produce the Rebol source notation for that binary). To mitigate the damage caused by this, TO-STRING undecorated will not operate on BINARY! for the near term unless a refinement specifying the /BASE is provided. This will allow callsites to review if they want to use FORM (which will do the UTF8 decoding) or take the mold behavior.

This is discussed in the Ren-C Trello and elsewhere, but this issue is closed in any case.