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

> 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