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