semantics and portability

[Marc Feeley]

The meaning of --r5rs, --srfi-0, --srfi-7 is not clear to me.
Does --srfi-0 imply --r5rs, and does --srfi-7 imply --r5rs and not --srfi-0?
In other words, what can I rely on if I say --srfi-0 (note that SRFI 0
is not (currently) powerful enough to test for the existence of R5RS).

Moreover there are serious portability problems with this proposal,
which is really unfortunate since the goal of SRFI 22 is to allow
users to write scripts that are portable to different Scheme
installations.

1) What if an implementation is not **completely** compliant to R5RS
(basically all the implementations of Scheme... some aren't properly
tail-recursive, some don't have call/cc, some don't parse tokens
exactly as required, etc.). Does this mean it can't conform to SRFI 22?

2) It is likely that a Scheme implementation will only support a subset
of the 3 "languages" (R5RS, SRFI 0, SRFI 7). So which of the three
should a user specify to maximize portability. Shouldn't one of them
be mandatory? I would vote for SRFI 0 + R5RS to be mandatory.

3) If a user's favorite implementation of Scheme does not support all
3 languages, he may want to install another implementation of
Scheme that supports the remainder. With the current command-line
selection of language, this is difficult to accomplish (unless an
additional level of trampoline is added by the user, which would be
a needless burden). So I propose that the name of the language be
part of the executable's name:

scheme-script-r5rs ... instead of: scheme-script --r5rs ...
scheme-script ... instead of: scheme-script --srfi-0 ...
scheme-script-srfi-7 ... instead of: scheme-script --srfi-7 ...

4) It should be mentionned explicitly that the standard input and
output of the script are connected to (current-input-port) and
(current-output-port), and not the controlling terminal, so that
redirection works properly.

5) Similarly, statements about the environment variables visible by
the Scheme program, and such things should be made explicit.

6) It would be nice to design a scripting system that also works with
Windows. I don't know how compatible this proposal is (and I am no
expert) but someone should look into it.

Marc

[sperber-jNDFPZUTrfQQDnmTUQnR1uqEdJ8o/ (Michael Sperber [Mr. Preprocessor])]

Marc> The meaning of --r5rs, --srfi-0, --srfi-7 is not clear to me.
Marc> Does --srfi-0 imply --r5rs, and does --srfi-7 imply --r5rs and
Marc> not --srfi-0? In other words, what can I rely on if I say
Marc> --srfi-0 (note that SRFI 0 is not (currently) powerful enough to
Marc> test for the existence of R5RS).

SRFI 0 implies R5RS. I'll try to make this more clear in the next
revision.

Marc> Moreover there are serious portability problems with this proposal,
Marc> which is really unfortunate since the goal of SRFI 22 is to allow
Marc> users to write scripts that are portable to different Scheme
Marc> installations.

Marc> 1) What if an implementation is not **completely** compliant to R5RS
Marc> (basically all the implementations of Scheme... some aren't
Marc> properly tail-recursive, some don't have call/cc, some don't
Marc> parse tokens exactly as required, etc.). Does this mean it
Marc> can't conform to SRFI 22?

Yes, that's what it means. I'll specify this more clearly in the next
revision. I don't see any point in dealing with proper subsets of
R5RS if we want scripts to be able to run.

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> 3) If a user's favorite implementation of Scheme does not support all
Marc> 3 languages, he may want to install another implementation of
Marc> Scheme that supports the remainder. With the current command-line
Marc> selection of language, this is difficult to accomplish (unless an
Marc> additional level of trampoline is added by the user, which would be
Marc> a needless burden). So I propose that the name of the language be
Marc> part of the executable's name:

Marc> scheme-script-r5rs ... instead of: scheme-script --r5rs ...
Marc> scheme-script ... instead of: scheme-script --srfi-0 ...
Marc> scheme-script-srfi-7 ... instead of: scheme-script --srfi-7 ...

That sounds reasonable.

Marc> 4) It should be mentionned explicitly that the standard input and
Marc> output of the script are connected to (current-input-port) and
Marc> (current-output-port), and not the controlling terminal, so that
Marc> redirection works properly.

Good point.

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?

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.

[Per Bothner]

Post by sperber-jNDFPZUTrfQQDnmTUQnR1uqEdJ8o/ (Michael Sperber [Mr. Preprocessor])
Marc> 1) What if an implementation is not **completely** compliant to R5RS
Marc> (basically all the implementations of Scheme... some aren't
Marc> properly tail-recursive, some don't have call/cc, some don't
Marc> parse tokens exactly as required, etc.). Does this mean it
Marc> can't conform to SRFI 22?
Yes, that's what it means. I'll specify this more clearly in the next
revision. I don't see any point in dealing with proper subsets of
R5RS if we want scripts to be able to run.

Well, it is likely that 99%+ of useful scripts do not need full
tail-calls or call/cc. Also, some implementation may be able to
support tail-calls and full call/cc but much slower.

What about the optional features of r5rs? The same arguments apply
to being able to handle say bignums or complex numbers. Again, 99%
of useful scripts probably need neither, and many Scheme implementations
do not support them. Does --r5rs require the optional features?

Perhaps we should have an option (or default) to specify
"mini-Scheme": r4rs minus optional features minus call/cc (except
perhaps for exits) and minus tail-calls (except self-tail-calls in do,
let, or named function).

[sperber-jNDFPZUTrfQQDnmTUQnR1uqEdJ8o/ (Michael Sperber [Mr. Preprocessor])]

Per> sperber-jNDFPZUTrfQQDnmTUQnR1uqEdJ8o/***@public.gmane.org (Michael Sperber [Mr. Preprocessor]) writes:

Marc> 1) What if an implementation is not **completely** compliant to R5RS
Marc> (basically all the implementations of Scheme... some aren't
Marc> properly tail-recursive, some don't have call/cc, some don't
Marc> parse tokens exactly as required, etc.). Does this mean it
Marc> can't conform to SRFI 22?

Post by sperber-jNDFPZUTrfQQDnmTUQnR1uqEdJ8o/ (Michael Sperber [Mr. Preprocessor])
Yes, that's what it means. I'll specify this more clearly in the next
revision. I don't see any point in dealing with proper subsets of
R5RS if we want scripts to be able to run.

Per> Well, it is likely that 99%+ of useful scripts do not need full
Per> tail-calls or call/cc. Also, some implementation may be able to
Per> support tail-calls and full call/cc but much slower.

I don't know that. I lot of code I write does depend on tail calls,
and I'd hate to change that habit for scripts. Moreover, I'd say that
(given the tectonic nature of Perl execution, for example), speed is
not very crucial for most scripts.

Per> What about the optional features of r5rs? The same arguments apply
Per> to being able to handle say bignums or complex numbers. Again, 99%
Per> of useful scripts probably need neither, and many Scheme implementations
Per> do not support them. Does --r5rs require the optional features?

That's a good point, but I'm not sure there's a clear answer. (Note
that "optional" in R5RS is probably not what you mean. Or is it?)
Many Schemes *do* support all of these. In fact, all Schemes I use
regularly do.

The question is really where you want to make the split between
Schemes which can support SRFI 22 and those which cannot. Should SIOD
be able to support SRFI 22, for instance?

Per> Perhaps we should have an option (or default) to specify
Per> "mini-Scheme": r4rs minus optional features minus call/cc (except
Per> perhaps for exits) and minus tail-calls (except self-tail-calls in do,
Per> let, or named function).

Again, I think specifying a language dialect outside of the existing
standards is outside the purview of this SRFI. Much better to handle
this kind of thing in a separate SRFI. I'd definitely consider --r4rs
and --ieee-1178-1990 viable options, as many Schemes currently do not
support DEFINE-SYNTAX all that well, even though, once again, I often
use DEFINE-SYNTAX.

[Marc Feeley]

Post by sperber-jNDFPZUTrfQQDnmTUQnR1uqEdJ8o/ (Michael Sperber [Mr. Preprocessor])
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.

Post by sperber-jNDFPZUTrfQQDnmTUQnR1uqEdJ8o/ (Michael Sperber [Mr. Preprocessor])
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".

Post by sperber-jNDFPZUTrfQQDnmTUQnR1uqEdJ8o/ (Michael Sperber [Mr. Preprocessor])
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

[sperber-jNDFPZUTrfQQDnmTUQnR1uqEdJ8o/ (Michael Sperber [Mr. Preprocessor])]

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.

Post by sperber-jNDFPZUTrfQQDnmTUQnR1uqEdJ8o/ (Michael Sperber [Mr. Preprocessor])
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.

Post by sperber-jNDFPZUTrfQQDnmTUQnR1uqEdJ8o/ (Michael Sperber [Mr. Preprocessor])
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.

[sperber-jNDFPZUTrfQQDnmTUQnR1uqEdJ8o/ (Michael Sperber [Mr. Preprocessor])]

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

After rereading this, I'm still not sure I get it. "scheme-script"
*is* the underlying interpreter, no?

[Marc Feeley]

Post by sperber-jNDFPZUTrfQQDnmTUQnR1uqEdJ8o/ (Michael Sperber [Mr. Preprocessor])
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".
After rereading this, I'm still not sure I get it. "scheme-script"
*is* the underlying interpreter, no?

Well it could be the executable for the interpreter, but it could also
be a shell script that execs the appropriate underlying interpreter
(Gambit, Scheme48, etc) after doing some administrative checks (that
the user has permission to run the interpreter, logging the use of
a Scheme script, or whatever). For example, I can perfectly imagine
Gambit's interpreter to reside in "gsi" and "scheme-script"
is a shell script like this

#! /bin/sh
... parse command line options BUT DON'T CHANGE THE ENVIRONMENT!
exec gsi ...

This means that old versions of Gambit, and probably most current
implementations of Scheme, can be SRFI 22 compliant if the appropriate
shell script is written for "scheme-script".

In future versions of Gambit I plan to install a symbolic link from
"scheme-script" to "gsi" and let gsi do the special SRFI 22 command line
parsing.

Marc

[sperber-jNDFPZUTrfQQDnmTUQnR1uqEdJ8o/ (Michael Sperber [Mr. Preprocessor])]

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

Post by sperber-jNDFPZUTrfQQDnmTUQnR1uqEdJ8o/ (Michael Sperber [Mr. Preprocessor])
After rereading this, I'm still not sure I get it. "scheme-script"
*is* the underlying interpreter, no?

Marc> Well it could be the executable for the interpreter, but it could also
Marc> be a shell script that execs the appropriate underlying interpreter
Marc> (Gambit, Scheme48, etc) after doing some administrative checks (that
Marc> the user has permission to run the interpreter, logging the use of
Marc> a Scheme script, or whatever). For example, I can perfectly imagine
Marc> Gambit's interpreter to reside in "gsi" and "scheme-script"
Marc> is a shell script like this

Marc> #! /bin/sh
Marc> ... parse command line options BUT DON'T CHANGE THE ENVIRONMENT!
Marc> exec gsi ...

Hmmm, what do we do to help Scheme implementations like PLT whose
front-end script *needs* to set internally used environment variables
like PLTHOME or PLTCOLLECTS? This is unlikely to interfere with the
script, but it sure breaks the guarantee you're suggesting.

I'm searching for some wording in the
SRFI 22, and haven't come up with anything that fits yet.

[Marc Feeley]

Post by sperber-jNDFPZUTrfQQDnmTUQnR1uqEdJ8o/ (Michael Sperber [Mr. Preprocessor])
Hmmm, what do we do to help Scheme implementations like PLT whose
front-end script *needs* to set internally used environment variables
like PLTHOME or PLTCOLLECTS? This is unlikely to interfere with the
script, but it sure breaks the guarantee you're suggesting.

I think it would be reasonable to say that PLT does not conform to
SRFI 22 (if this practice is maintained). This kind of "environmental
pollution" is bound to cause problems when a script needs to access
the (shell) environment. After all if I write this script for my
"Pretty Little Thing" application and I decide "PLTHOME" is the
environment variable to use for this application, then my script won't
be portable to PLT Scheme. And if every implementation has the
"right" to pollute the environment in its own way then it will become
next to impossible to write portable scripts that access the
environment.

By the way, I feel SRFI 22 is the right place to introduce a "getenv"
procedure, because SRFI 22 clearly is about the interaction between a
Scheme program and its invocation from the shell, and also it has
a definite UNIX bias.

Post by sperber-jNDFPZUTrfQQDnmTUQnR1uqEdJ8o/ (Michael Sperber [Mr. Preprocessor])
I'm searching for some wording in the
SRFI 22, and haven't come up with anything that fits yet.

"Zero tolerance for environmental pollution."

Marc

[sperber-jNDFPZUTrfQQDnmTUQnR1uqEdJ8o/ (Michael Sperber [Mr. Preprocessor])]

Marc> By the way, I feel SRFI 22 is the right place to introduce a "getenv"
Marc> procedure, because SRFI 22 clearly is about the interaction between a
Marc> Scheme program and its invocation from the shell, and also it has
Marc> a definite UNIX bias.

I can see your point. Should we then also include "exit"?

[Marc Feeley]

Post by sperber-jNDFPZUTrfQQDnmTUQnR1uqEdJ8o/ (Michael Sperber [Mr. Preprocessor])
Marc> By the way, I feel SRFI 22 is the right place to introduce a "getenv"
Marc> procedure, because SRFI 22 clearly is about the interaction between a
Marc> Scheme program and its invocation from the shell, and also it has
Marc> a definite UNIX bias.
I can see your point. Should we then also include "exit"?

Go for it.

Marc