This page is part of the web mail archives of SRFI 98 from before July 7th, 2015. The new archives for SRFI 98 contain all messages, not just those from before July 7th, 2015.
Hi, Thank you for your active discussion. Abdulaziz Ghuloum wrote: >One other inconvenience is that you have to wrap every call to >get-environment-variable with some sort of a guard. I see. shiro wrote: > Ultimately, the choice depends on the purpose of this srfi. > If this one just wants to summarize "current practices", leave > the behavior undefined and cross your fingers that it works > "most of the time". If this one wants to provide a portable > and robust basis, specify the behavior and encourage existing > implementations to follow. I tend to vote the latter. Thank you for your kind explanation. It was clear enough for me to understand what you meant. I want to summarize "current practices". So I suggest for keeping it simple we summarize "current practices" in this srfi. Fortunately, your suggestion (c) is not inconsistent with simple one, we can leave some rare cases to another srfi. --- Taro Minowa(Higepon) http://www.monaos.org/ http://code.google.com/p/mosh-scheme/ On Mon, Jul 21, 2008 at 4:12 AM, Shiro Kawai <shiro@xxxxxxxx> wrote: > From: higepon <higepon@xxxxxxxxx> > Subject: Re: getenv vs. locale > Date: Sun, 20 Jul 2008 21:33:54 +0900 > >> Thank you for your suggestions. >> >> > (a) Raises an exception (natural, but may be inconvenient in some cases) >> > (b) Returns some value indicating such condition has happened >> > (c) Allow an optional 'filter' argument. >> >> I think (a) is good. >> It is enough for my usage (CGI applications). >> >> What cases are inconvenient? >> Procedures return raw value(s) are necessary? > > Initially I thought it would be cumbersome to wrap every > occurrence of getenv if I wanted to make sure getenv won't > stop an application. But maybe it's not so bad, since giving a > proper filter argument is probably equally cumbersome. And > in either way, you can't change the behavior of getenvs used > within third-party libraries. So, the advantage of (c) is > greater flexibility, including the integration of raw value > handling into getenv function. > (Alternatively, the condition thrown by getenv may include > the offending value in it.) > > Do we need raw value handling? Well, maybe. I tend to say > yes because of my tendency to try to cover all possible cases, > but am not sure its practical implication. Besides the > obvious use cases such as logging and fancy error reporting, > what I can think of is contrived examples such as > the value of PWD includes a multibyte directory name whose > encoding is different from the process's locale and you > might want to convert it implicitly. > > The option (c) is difficult to implement on top of the > existing implementations, in most of which getenv is a primitive > procedure returning a string (but there's the same difficulty > in the option (a) if you want to define a specific condition > getenv should throw). > > Ultimately, the choice depends on the purpose of this srfi. > If this one just wants to summarize "current practices", leave > the behavior undefined and cross your fingers that it works > "most of the time". If this one wants to provide a portable > and robust basis, specify the behavior and encourage existing > implementations to follow. I tend to vote the latter. > (It would be very annoying if my application calling > get-environment-variables keeps failing on the user's machine > but not on my machine, and finding out it's because a single > value in some obscure environment variable.) > > --shiro >