This page is part of the web mail archives of SRFI 22 from before July 7th, 2015. The new archives for SRFI 22 contain all messages, not just those from before July 7th, 2015.
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