Re: semantics and portability

[sperber@xxxxxxxxxxxxxxxxxxxxxxxxxxx (Michael Sperber [Mr. Preprocessor])]

>>>>> "Marc" == Marc Feeley <feeley@xxxxxxxxxxxxxxxx> writes:

Marc> The meaning of --r5rs, --srfi-0, --srfi-7 is not clear to me.
Marc> Does --srfi-0 imply --r5rs, and does --srfi-7 imply --r5rs and
Marc> not --srfi-0?  In other words, what can I rely on if I say
Marc> --srfi-0 (note that SRFI 0 is not (currently) powerful enough to
Marc> test for the existence of R5RS).

SRFI 0 implies R5RS.  I'll try to make this more clear in the next
revision.

Marc> Moreover there are serious portability problems with this proposal,
Marc> which is really unfortunate since the goal of SRFI 22 is to allow
Marc> users to write scripts that are portable to different Scheme
Marc> installations.

Marc> 1) What if an implementation is not **completely** compliant to R5RS
Marc>    (basically all the implementations of Scheme... some aren't
Marc>    properly tail-recursive, some don't have call/cc, some don't
Marc>    parse tokens exactly as required, etc.).  Does this mean it
Marc>    can't conform to SRFI 22?

Yes, that's what it means.  I'll specify this more clearly in the next
revision.  I don't see any point in dealing with proper subsets of
R5RS if we want scripts to be able to run.

Marc> 2) It is likely that a Scheme implementation will only support a subset
Marc>    of the 3 "languages" (R5RS, SRFI 0, SRFI 7).  So which of the three
Marc>    should a user specify to maximize portability.  Shouldn't one of them
Marc>    be mandatory?  I would vote for SRFI 0 + R5RS to be mandatory.

No, since implementations supporting SRFI 7 will not (and currently do
not and will not in the future) always support SRFI 0.  This means at
most R5RS can be mandatory.

Marc> 3) If a user's favorite implementation of Scheme does not support all
Marc>    3 languages, he may want to install another implementation of
Marc>    Scheme that supports the remainder.  With the current command-line
Marc>    selection of language, this is difficult to accomplish (unless an
Marc>    additional level of trampoline is added by the user, which would be
Marc>    a needless burden).  So I propose that the name of the language be
Marc>    part of the executable's name:

Marc>      scheme-script-r5rs ...    instead of:  scheme-script --r5rs ...
Marc>      scheme-script ...         instead of:  scheme-script --srfi-0 ...
Marc>      scheme-script-srfi-7 ...  instead of:  scheme-script --srfi-7 ...

That sounds reasonable.

Marc> 4) It should be mentionned explicitly that the standard input and
Marc>    output of the script are connected to (current-input-port) and
Marc>    (current-output-port), and not the controlling terminal, so that
Marc>    redirection works properly.

Good point.

Marc> 5) Similarly, statements about the environment variables visible by
Marc>    the Scheme program, and such things should be made explicit.

What exactly were you thinking about?  This would entail standardizing
getenv and putenv, which I don't really want to do in this SRFI, no?

Marc> 6) It would be nice to design a scripting system that also works with
Marc>    Windows.  I don't know how compatible this proposal is (and I am no
Marc>    expert) but someone should look into it.

Sure, but that's not within the purview of this SRFI, I think.

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