> Marc Feeley <xxxxxx@IRO.UMontreal.CA> writes:
>
> >   #! /bin/sh
> >   "exec" "scheme-script" "$0" "$@"
> >   (define (main arg1 arg2)
> >     (write (+ (string->number arg1) (string->number arg2))))
> >   (apply main (command-line-arguments))
>
> I prefer this approach.  I think it is more compatible with the
> traditional "load".
>
> The Kawa compiler can take this kind of script, and if you compile
> it with --main you get a stand-alone Java application.  If you load
> it, you get the behavior expected of the script. I don't think the
> rationale for easier debugging is strong enough to compensate for
> a clumsier and less traditional interface.
>
> I think "script-arguments" is not a good name.  What is a "script"?
> Why the word "script" as apposed to "program" or "application"?
> "command-line-arguments" is both more descriptive and avoids the
> "script" vs "program" issue.  It is so descriptive that both Scsh
> and Kawa use it - but they use it for a global variable.  Using it
> for a function would clash.  Scsh does have "(command-line)" which
> returns the complete command line, including the name the script
> was executed as.

I introduced the name "script-arguments" to distinguish it from the
name "command-line-arguments" I used in previous examples (and in fact
in the example you quote above).  The call (command-line-arguments)
always returns the list of command line arguments.  I introduced
(script-arguments) to have a different meaning when executed in the
dynamic extent of a "load" (i.e. an error).  Although I am open to
different names, I think it is important in this case that "script"
appear in the name to highlight that it should only be used in a
script.

You could define

  (define (script-arguments)
    (if (in-the-dynamic-extent-of-a-load?)
        (error "Attempt to load a script in an inappropriate context")
        (command-line-arguments)))

I'm don't know the rationale for Scsh's use of a global variable for
"command-line-arguments", but I don't like such an interface (I prefer
to hide the information behind a function so that the behaviour can be
changed more easily).

Marc