[R6RS] Scripts and toplevel code
Anton van Straaten
anton at appsolutions.com
Thu Aug 17 03:44:09 EDT 2006
> R6RS presumably won't specify any mechanism for starting up a Scheme
> session, so I don't see why it's any bigger hole not to have a mechansim
> for loading and running a script.
Because with other kinds of code, it's possible to use 'import' and
access the definitions exported by that code. It seems fairly unusual
to me to have a class of code that has no defined way of being accessed
programmatically from within the language, short of spawning a shell.
I'm not saying that this is unacceptable, but I see it as a weakness in
any proposal which involves anonymous scripts, and I was trying to
> But if we do specify a mechanism to
> load and run a script, it's no easier with the script form than without.
All I meant is that if scripts are named, and can be treated as
libraries, then other code can simply use 'import' to load and/or run
those scripts. This assumes that the behavior of the script is known --
whether 'import' actually causes a script to run would depend on the script.
It also assumes that an implementation can find the library, but that
seems to be outside the scope of R6RS - to use a script as a library,
you'd have to comply with the implementation's requirements on where
libraries should be located.
This approach would provide a degree of portable programmatic control
over scripts, that otherwise would require a new mechanism (or a
resurrection of 'load').
>>If the script form were treated as a library, then the named entry point
>> would be its sole export, which would allow other libraries to control
> Not really, because of the body code that's executed when the script being
> treated as a library is invoked.
Someone wanting to manipulate scripts programmatically would make use of
the entry point feature, and avoid body code that does unwanted things.
Someone relying on body code would have to understand that it can
hamper programmatic manipulation.
>>Of course, an alternative in this context would be to have
>>scripts export all their top-level definitions.
> To me, this is an issue of the interactive environment, and we shouldn't
> be designing the syntax of scripts around that.
If scripts export all their definitions, and are mapped to libraries,
then I see them more as libraries with no visibility control, rather
than anything to do with the interactive environment. See below for why
one might want this.
> We should focus on what
> makes scripts most useful as scripts and thereby encourages the most
Agreed, but that's one of my concerns: what happens when you write a
script, and then want to load that script from another script?
If scripts are anonymous and not portably load-able, then you'd have to
convert the first script to a library at that point. In that case, it
would cease to be a script, so couldn't be run independently as a
script. You'd be further forced to factor the script into a library and
a small script which imports that library. I'm all for encouraging good
coding practices, but I think we may pushing the envelope here in a way
that will affect usability.
I was hoping that the script feature could be an escape hatch into a
slightly less rigorous world, and that it would be up to the programmer
to choose the point at which the switch from scripts to libraries is made.
Related to this, in another message you wrote:
> Personally, I'd rather not require that implementations treat files
> containing script headers as libraries, no matter how they are
> structured. It seems like this could lead to compatibility
> complications down the road. The simpler we make our R6RS
> libraries, the easier it will be for R7+RS implementations to
> handle them.
I'm not sure I see the problem here - the script header seems easy
enough to ignore, even on e.g. Windows. It seems fairly benign to me,
but I may be missing something.
> At one point, Matthew was opposed to having multiple libraries in one
> file, and I think it's best if we don't force the issue one way or another
> by defining a syntax in which multiple libraries are possible.
More information about the R6RS