1. The command-line syntax is a bit verbose, e.g. the "-call"
   switch serves no purpose. The command line could simply
   be
       scheme-script -r5rs <file> <entry-point> <arg1> ...

   On the other hand, this redundancy may allow extensions,
   so perhaps it's for the best.

2. It is a general Unix convention that interpreters read from their
   stdin, but alternately take a
       -c <exp>
   switch. You might consider adding this as an alternate to the
       -call <entry-point>
   option.

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'm not saying "don't do /bin/sh trampolines." I am saying, "Allow
   the direct alternative, too." This is enabled by the meta switch.

   I have implemented the scsh spec for the meta switch in both Scheme
   and bulletproof C; I will make this source available to this SRFI
   under the SRFI's copyright, if desired.

   I have written a lot of my notebook's /etc/scripts in Scheme. Part of
   the point was to get /bin/sh out of my life. Ideologically speaking,
   I resent *having* to be dependent on it to run a Scheme script.

4. This is a bogus spec:
     <script prelude> --> #! <any character including newline> !#
   One problem is the singular "character", when you mean multiple
   characters, of course. And the "anything including newline" spec
   isn't right, either, since !# isn't allowed. Here's my version:
     <script prelude> -->
	 #! <any sequence of chars not containing bang-sharp> !#
   Is that better?

   Also, I'd suggest making the terminator be newline-bang-sharp, not
   simply bang-sharp. Makes the possibility of a false positive even
   less likely.

5. The draft says
     In the case of -srfi7 all specifications of filenames (marked by
     <filename> in the syntax of SRFI 7) are strings containing Unix-style
     filenames relative to the directory the script resides in.

   Err... are you *sure* you want to do that? Invariably, a relative
   pathname in Unix means relative to the process' cwd. You are changing that
   rule, *only* in the case of code appearing in a Scheme script. That
   could cause weird surprises...

   This is problematic for other reasons, as well. What if I want to load
   stuff in from some standard library directory, regardless of where you
   might locate my script? Are you disallowing absolute pathnames?

   If you really want to do this relative-to-the-script pathname resolution,
   you might be better off saying that *relative* pathnames are interpreted
   this way, and absolute pathnames are simply absolute filenames.

   Also, you are dangling a preposition.

    -Olin