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