[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: semantics and portability
>>>>> "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> 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.
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