[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: compilability of scripts

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.

>>>>> "Marc" == Marc Feeley <feeley@xxxxxxxxxxxxxxxx> 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