Email list hosting service & mailing list manager

compilability of scripts Marc Feeley (10 Mar 2001 17:33 UTC)
Re: compilability of scripts sperber@xxxxxx (20 Mar 2001 10:55 UTC)
Re: compilability of scripts Marc Feeley (20 Mar 2001 12:43 UTC)

Re: compilability of scripts sperber@xxxxxx 20 Mar 2001 10:55 UTC

>>>>> "Marc" == Marc Feeley <xxxxxx@IRO.UMontreal.CA> writes:

Marc> the syntax of the shell part of the script should be a well
Marc> defined subset of the shell syntax, for example always of the form:

Marc>         exec scheme-script "$0" --call <identifier> "$@"

We'll put something like this in the next revision.

Marc> 2) Use the compiler to generate a "FASL file" (a compiled
Marc>    representation of "S.scm" that can be loaded quickly), say
Marc>    "S.fasl".  This can be a bytecode file, a binary file, heap image,
Marc>    etc.  Scheme implementations which can generate FASL files
Marc>    typically allow loading the file with (load "S.fasl") or a command
Marc>    line option.  Note that it is possible to define "scheme-script" so
Marc>    that when

Marc>         S.scm arg1 arg2 arg3

Marc>    calls "scheme-script S.scm ...", it will load the file "S.fasl"
Marc>    instead of "S.scm" if "S.fasl" exists.  For this to work and be
Marc>    portable, SRFI 22 would have to define the filename extension of
Marc>    FASL files, or specify that an implementation dependent search is
Marc>    performed for a file to load with the same base name (i.e. "S").

Marc>    Alternatively, this search for the file to load could be done by
Marc>    "scheme-script" only if the script file argument has no extension
Marc>    (under UNIX you can only invoke a script with the same extension as
Marc>    its filename, but under Windows, scripts must have the extension
Marc>    ".BAT" or ".CMD" and can be invoked with or without the extension).
Marc>    So, a script "S.scm" will always load "S.scm", but a script "S" may
Marc>    load "S.fasl", "S.foobar", "S.bat", "S", etc.

Is it really necessary to put something like this in the SRFI
document?  After all, the details of this are likely
necessarily implementation-dependent, and the SRFI surely doesn't
prevent an implementation from supporting something like this
without losing portability of the script source code.

--
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla