This page is part of the web mail archives of SRFI 22 from before July 7th, 2015. The new archives for SRFI 22 contain all messages, not just those from before July 7th, 2015.
> 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