> 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