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.
Here are my comments: The name "scm-i3e1178-90" is bizarre and I will not remember it. Why not "scm-ieee-1178-1990"? Also I don't like the prefix "scm-"... why not the more explicit "scheme-" prefix? I think the 32 character limit for the script-interpreter line is a lame argument. It is hard to find a Unix that has this limit and in any case the line #! /usr/bin/env scheme-srfi-0 (which I hope will be the most frequent case) is 3 characters short of the 32 character limit (sorry to those fans of the IEEE standard wanting to be portable to very old Unices!). Note that you should use the path "/usr/bin/env" which is more standard than "/bin/env" (for example on MacOS X "/bin/env" does not exist). In the document you say: Single-Line vs. Multi-Line Invocation Another common convention for implementing Unix scripts is simply to treat an initial line starting with #! specially and using the terminating newline as the delimiter. However, some Unix implementations limit the length of this line and/or the number of command-line parameters available on it. Therefore, a special terminating delimiter different from newline is necessary. This comment only makes sense if you buy the 32 character limit argument and there are (many) options to pass to the script interpreter, or the path is long. But in fact, by using the "/usr/bin/env" trampoline, a path is not needed on the interpreter, and there are no SRFI-22 specific options to pass to the interpreter. The need for a multi-line invocation is just not there and it makes processing of the script header more complex. SRFI-22 could simply say that a script must start with the single line #! /usr/bin/env scheme-XXX and that's it, the next line is Scheme code. It is portable, it can easily be parsed by a Scheme script compiler, and finally a UNIX script can be converted to Windows by replacing "#! /usr/bin/env " by "@;", which can be automated very simply. I don't see the need for several ways of writing a SRFI-22 compliant script (trampoline or not, /usr/bin/env or /bin/sh or other trampoline, etc). It is bound to make the scripts less portable (I can easily imagine someone using a "/bin/sh" script with an option that is not standard, or a trampoline that is not standard, like "/bin/env"). By adopting a single well defined syntax we avoid such portability problems. Obviously, individual users can write scripts as they please, but SRFI-22 should take a strong position regarding portability. SRFI-22 compliance should be both a property of Scheme systems **and** Scheme scripts. Finally, I don't understand the sudden change in the way parameters are passed to "main". It seems much more elegant to define "main" as a procedure with as many arguments as are needed by the script, which allows the Scheme interpreter to very naturally catch wrong number of argument errors, and the code for scripts expecting a fixed number of arguments is more elegant (they don't have to extract the arguments from a list). Scripts that handle variable number of arguments (such as your example) can be written with a rest parameter: (define (main . arguments) (for-each display-file arguments) 0) Marc