[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: semantics and portability

This page is part of the web mail archives of SRFI 22 from before July 7th, 2015. The new archives for SRFI 22 are here. Eventually, the entire history will be moved there, including any new messages.



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