[R6RS] Scripts and toplevel code

[Anton van Straaten]

dyb at cs.indiana.edu wrote:
>>#!/usr/bin/env scheme-script
>>#!r6rs
>>(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 
issue.

> 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.

Anton