DO vs. IMPORT and "Console-Extending Applications"

[rgchris]

I'm visiting this topic as I am contemplating modules vs. scripts and more practically, why IMPORT and DO (or DO*) are in SYS-LOAD and SYS-BASE respectively. There seems to be a lot of crossover between IMPORT and DO* and having them defined in different sources precludes sharing common code.

A part of my interest is in the distinction that when you DO a module in Rebol 3, it will update SYSTEM/SCRIPT, whereas when you IMPORT a module, it does not. The implication of this is that when importing a module (including from the NEEDS header which I am in favour of), you don't have any way to access the Module's header or location.

Further, if you DO a module twice, the module is IMPORTed on the first run, but then DO evaluates the code again on the second go (where IMPORT checks to see if it is now in the list of imported modules). This breaks my conception of what a module should be, which, I'd say is muddied by all the various goals and distinctions of scripts and modules.

I'd have assumed that SYS-LOAD would be concerned with the transformation from text/binary to values and that IMPORT is superfluous to this end. Perhaps the implication of having IMPORT in there is connected with the idea it's impossible to LOAD a module without running IMPORT on its needs. I'm not so sure about this.

Scripts vs. Modules vs. Unnamed Modules

In BrianH's epic StackOverflow answer on Words in Modules, he describes the various distinctions between Module types and the distinction between Scripts: paraphrasing—scripts are like modules, but all scripts share the same word space, system/contexts/user. Ok, this seems fine. He also describes Unnamed Modules as not being trackable, and thus suitable for code that is run for effect but in a private word space. That would be consistent with DO running it multiple times, but inconsistent with IMPORT.

I think this gets me to the same conclusion as you:

@hostilefork

An "ideal" module would not have any "side-effects"...because the concept was that no matter how many times you run IMPORT you will only get one copy of that module in memory.

@hostilefork

The nice thing about the word DO is it sounds pretty unambiguous, that you want to run something that has side effects.

But I do like the default of not leaking into the enclosing environment.

I think this could all be codified. Modules load once and must be indexed (preferably by URL instead of name), and a Script should have an option to have its own word space (even if the mechanism for doing so is MODULE!).

Additional takes include: Modules should not automatically export to LIB (which is #2115); need functional type headers.

Caveat: I realize I might be out of date in the ways Ren-C diverges from Rebol 3 when it comes to this stuff, however I notice the SYS-LOAD/IMPORT, SYS-BASE/DO* delineation still exists.