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> 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> I think you misunderstood me. I don't think so. Marc> I mean that to conform to SRFI 22 an Marc> implementation has to provide support for the "language" --srfi-0 . Marc> An implementation may also provide support for --r5rs and --srfi-7 but Marc> it is optional. So when I want to write a script that is maximally Marc> portable I know that --srfi-0 must be used. A minimal implementation Marc> of srfi-0 is so easy that I can't really see the utility of the --r5rs Marc> language option. Note that even if the underlying interpreter does Marc> not support SRFI 0 natively (I'm thinking of Scheme48 in particular) Marc> the "scheme-script" executable can explicitly add it to the initial Marc> environment. Well sure, but the language annotation also has documentation function which I'd like to preserve. Also, I was talking about the political side of the issue as much as the technical. Marc> No. All I am saying is that the process started to run the underlying Marc> interpreter should have the same (shell) environment as the one of Marc> "scheme-script". If the underlying interpreter supports some kind of Marc> "getenv" procedure, then we know what it refers to. I'm sure you were Marc> assuming that this was the case, but I'd like the SRFI to spell it Marc> out. I don't want "scheme-script" to add, modify, or remove any of Marc> the environment variables that are in effect at the invocation of Marc> "scheme-script". That sounds reasonable. 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. Marc> Well as (one of) the authors you are free to set your own goals, but Marc> it would be unfortunate to end up with something that is needlessly Marc> incompatible with Windows because that means scripts aren't portable Marc> between UNIX and Windows. Note that it may be impossible to have a Marc> portable script structure, but let's not rule it out too quickly. Marc> I'll look into it some more. It sure would be nice. -- Cheers =8-} Mike Friede, Völkerverständigung und überhaupt blabla