If you have a script that is not a module, you may be motivated to make it a module in order to get the benefits of features like isolation. So if you have something like:
Rebol [
Title: "My fun script"
]
private-fun: function [] [print "I am private"]
fun: function [] [print "I am public" private-fun]
print "Type FUN for enjoyment"
1 + 2
You might want the behavior with DO to say:
>> do %my-fun-script.reb
Type FUN for enjoyment
== 3
Then, if you wanted to get the benefits of a module, you might change the header:
Rebol [
Title: "My fun script"
Type: Module
Options: [isolate]
Exports: [fun]
]
...BUT... doing this changes the behavior of DO to return a MODULE!, not the last thing evaluated to. If you've configured your console to print out the result (instead of hiding it like R3-Alpha does by default) you might get something like:
>> do %my-fun-script.reb
Type FUN for enjoyment
== make module! [
fun: 'make action! [[] [...]]
private-fun: 'make action! [[] [...]]
function: 'make action! [[spec body] [...]]
print: 'make action! [[line /html] [...]]
+: 'make action! [[value1 value2] [...]]
]
So once it's a module, DO no longer gets the result of the body. So this means modularized scripts are not directly interchangeable with non-modularized ones. That's inconvenient.
I'd propose that IMPORT be what returns a module. Then, DO of a module returns the body evaluative result...just as if the script were not a module.
Modules that are named in a header don't have any obvious place to convey their evaluative results to a script that Needs: them. But that's not to say there couldn't be a dialect for capturing them into variables if one wanted:
Needs: [My-Fun-Script => result-var] ; Random notational idea
(Note: The specific motivating example I have relates to a console configured to display modules, and not wanting the message to be missed. So there's no particularly interesting return result, and DO could just return VOID!. But as mentioned, this seems like a loss for any script which is just being modularized for context isolation and still wants to return a value.)
Hostilefork added Ren.important and Type.wish on Apr 15, 2019
Mark-hi commented on Apr 15, 2019:
(1) Aren't needed modules imported, hence result-var would only hold the module itself?
(2) Just confirming: if you want it silent when done your module body must end with a void, right?
Submitted by: Hostilefork
If you have a script that is not a module, you may be motivated to make it a module in order to get the benefits of features like isolation. So if you have something like:
You might want the behavior with DO to say:
Then, if you wanted to get the benefits of a module, you might change the header:
...BUT... doing this changes the behavior of DO to return a MODULE!, not the last thing evaluated to. If you've configured your console to print out the result (instead of hiding it like R3-Alpha does by default) you might get something like:
So once it's a module, DO no longer gets the result of the body. So this means modularized scripts are not directly interchangeable with non-modularized ones. That's inconvenient.
I'd propose that IMPORT be what returns a module. Then, DO of a module returns the body evaluative result...just as if the script were not a module.
Modules that are named in a header don't have any obvious place to convey their evaluative results to a script that Needs: them. But that's not to say there couldn't be a dialect for capturing them into variables if one wanted:
(Note: The specific motivating example I have relates to a console configured to display modules, and not wanting the message to be missed. So there's no particularly interesting return result, and DO could just return VOID!. But as mentioned, this seems like a loss for any script which is just being modularized for context isolation and still wants to return a value.)
Imported from: https://github.com/rebol/rebol-issues/issues/2373
Comments:
(1) Aren't needed modules imported, hence result-var would only hold the module itself? (2) Just confirming: if you want it silent when done your module body must end with a void, right?