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.
> 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