[R6RS] Scripts and toplevel code

[Anton van Straaten]

Michael Sperber wrote:
> But it seems that adding your proposal to the existing mix will make
> that quite hard, as the script can't evolve gracefully into a library:
> the forms in its body have to be re-arranged or augmented by "(define
> dummy-xxx ...)" , giving scripts bad continuity characteristics.
> 
> To my mind, this makes it worth reconsidering the restriction on
> library bodies.  This would enable us to say:
> 
> #!/usr/bin/env scheme-script
> #!r6rs
> (script <identifier>
>   (import ...)
>   <library body>)
> 
> where <identifier> names the entry point.  Change it into a library by
> changing "script" to "library", replacing <identifier> with the name
> of the library and adding an export clause.  This can be done with an
> editor macro.

In general, I like that this reduces the boilerplate by not requiring a 
separate clause to identify which library and entry point to use.

But one drawback to this (and to the toplevel code proposal that Kent 
and I discussed earlier) is that scripts are nameless, and would 
presumably require a special API to support loading and running them 
from a program, for testing or some kind of reuse.

So at the risk of re-cluttering the syntax, I'm thinking it could be 
worthwhile adding a script name, to allow scripts to be imported like 
libraries.  This would give a syntax like:

#!/usr/bin/env scheme-script
#!r6rs
(script <script name> <entry point name>
   (import ...)
   <library body>)

If we adopt Mike's proposal for listing exports in libraries first, then 
the script form and the library form would have parallel structure, with 
the entry point name in the script form replacing the export clause in 
the library form.  The difference between the script form and the 
library form would then just be:

a) The script form has a specified entry point with a known signature, 
i.e. a single parameter for the command line arguments.

b) The script form has no export clause, and scripts export only their 
entry point.  (Alternatively, scripts could export all their top-level 
names.)

* * *

Finally, in my quest to support relaxed scripts, one other thing I think 
could be useful is to allow omission of the entry point, so that a 
script would not be required to define an entry procedure, but could 
just rely on code at the top level of the script form.  Again, this 
increases user choice: someone wanting more rigor can specify and define 
an entry procedure.

Anton