[R6RS] Scripts and toplevel code
Anton van Straaten
anton at appsolutions.com
Wed Aug 16 17:51:54 EDT 2006
dyb at cs.indiana.edu wrote:
>>(script <script name> <entry point name>
>> (import ...)
>> <library body>)
> This is less verbose, but the <script name> is noise, and I object to
> including it just to support one implementation's debugging model.
My reason for suggesting it is that I'm concerned about having code
that's completely anonymous. Will R6RS then specify procedures for
loading and running scripts? If not, that would seem to be a hole in
the spec. Leveraging the existing mechanism for accessing libraries
seems like one of the simplest and most consistent ways to deal with the
> Also, I think that requiring an entry point to be defined is strictly less
> useful than not requiring one to be defined.
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. Of course, an alternative in this context would be to have
scripts export all their top-level definitions.
If scripts are anonymous and so can't be imported as libraries, then I
agree that the issue of an entry point is not all that important, and
can be dealt with by convention.
> ...but I think it's better to go with the lightweight syntax
> and estalish conventions for anything more structured.
The lightweight syntax, with no 'script' form, would also be fine with
me. I've just been looking for something that we could all agree on,
and that addressed the various issues.
Two advantages of using a 'script' form would be the ability to name and
therefore reuse scripts in a standard way, without introducing new
mechanisms for locating and loading code; and the ability to include
other libraries in the same file as a script, without encountering the
ambiguities which you raised in an earlier message.
More information about the R6RS