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

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.

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

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

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

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

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

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

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

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

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