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

Re: semantics and portability

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

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