[R6RS] Scripts and toplevel code
Anton van Straaten
anton at appsolutions.com
Wed Aug 16 16:48:52 EDT 2006
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
> (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:
(script <script name> <entry point name>
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
* * *
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.
More information about the R6RS