[R6RS] Scripts and toplevel code

[Anton van Straaten]

Kent wrote:
> 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 
address that.

> 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 
>>the script.
> 
> 
> 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
> users.

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.  

OK.

Anton