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