>>>>> "Marc" == Marc Feeley <xxxxxx@IRO.UMontreal.CA> 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