> 3. Your design essentially *requires* a /bin/sh trampoline. Which I find
>    annoying. Perl used to require this kind of trampoline, but as it
>    became a standard, that became unnecessary. Why not design a standard
>    with more "legs" for the future-- something that would also work well
>    in a world where one can rely on scheme-script occuring in a particular
>    directory?
>
>    All that is required is the introduction of the
>      \ <filename>
>    "meta switch" as described in scsh. Note that doing so still allows
>    for /bin/sh trampolines, so you can go either way -- it doesn't close
>    doors. But *not* specifying a meta-switch *does* close doors, since
>    the true Unix #! command line only allows *one* switch after the
>    interpreter name, and both interpreter & switch must usually fit within
>    32 chars. Your design absolutely won't work with the true Unix kernel
>    #! mechanism; you *have* to trampoline through /bin/sh. Again, this is
>    all handled by the meta-switch design, which is *much* cheaper than
>    a /bin/sh trampoline.

I too would like to allow "scheme-script" to be called directly after
the "#!" instead of having to use a /bin/sh trampoline.  I understand
that this may be "less portable" than the /bin/sh trampoline approach
in the short term.

However I don't like the \ meta switch as proposed by Olin.  What
bothers me most is that the second line of the script contains other
command line options.

But why do we need command line options for scheme-script?  If we
ignore the "--r5rs", etc switches which will go away when they are
part of the scheme-script executable name, there only remains the
"--call <identifier>" switch which indicates which procedure acts
as the script's "main".  But this could easily be avoided
by relying on the script's top level expressions to do the work
and have a procedure, such as "command-line-arguments", to get
a list of the command line arguments.  "scheme-script" would
simply treat the first command line argument as the script filename
and the rest as the script arguments.  So instead of writing

  #! /bin/sh
  "exec" "scheme-script" "$0" "--call" "main" "$@"
  (define (main arg1 arg2)
    (write (+ (string->number arg1) (string->number arg2))))

one would write

  #! /bin/sh
  "exec" "scheme-script" "$0" "$@"
  (define (main arg1 arg2)
    (write (+ (string->number arg1) (string->number arg2))))
  (apply main (command-line-arguments))

or in a few years (!) simply

  #! /bin/scheme-script
  (define (main arg1 arg2)
    (write (+ (string->number arg1) (string->number arg2))))
  (apply main (command-line-arguments))

The advantages of removing the "--call" switch are:

1) it avoids the need for a special mechanism to read additional
   command line options from the second line of the script.

2) simple handling of "#!" by the load procedure: if the "#!" object is
   the first datum read in a file, discard the rest of the line.

3) the file can be compiled easily (the compiler only has to discard
   the "#!" line like "load", and the rest of the file is a normal
   "program" which has all the control information (entry point)
   in normal Scheme syntax).

The only command line options I can foresee a need for, is to
configure the Scheme system in a special way (set minimal/maximal size
for the heap, debugging level, etc).  Gambit uses the prefix "-:" to
introduce these options, and for example

    gsi -:h1000,d2 foo.scm

means: set the maximal heap size to 1MB and set the debugging flag to
level 2 and then load "foo.scm".

Such options are clearly implementation dependent, and so a script
that uses such options is not portable by definition.  It may however
be useful for SRFI 22 to indicate restrictions on the syntax of the
script filename so that systems supporting configuration options don't
misinterpret a filename as an option.  This could be as simple as
saying that a Scheme script filename must not start with a dash.

Marc