Hi.

>  It also means that the reference implementation given for
>  Scheme48 is invalid (for Scheme48 after 1.3.)

Thank you.
I will remove the reference implementation for Scheme48.

On Thu, Jul 24, 2008 at 10:42 PM, Ivan Shmakov <xxxxxx@theory.asu.ru> wrote:
>>>>>> higepon  <xxxxxx@gmail.com> writes:
>
> [...]
>
>  >> 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.
>
>        It should be noted that `lookup-environment-variable' returns a
>        byte-vector-like object, namely, an ``OS string'', in Scheme48.
>        Despite the issues were already noted on the list, I'd like to
>        quote a related comment:
>
> --cut: scheme48/scheme/rts/os-string.scm--
> ; You may think that file names / environment variables / user names
> ; etc. are just text, but on most platforms, that assumption is wrong:
> ; They are usually NUL-terminated byte strings in some format.  The
> ; bytes are invariant, but the corresponding text may depend on the
> ; locale.  Also, byte sequences without a textual representation are
> ; possible.
>
> ; We assume that OS strings are encoded in some conservative extension
> ; of NUL-terminated ASCII.  On Unix, this assumption pretty much has
> ; to hold true because of the various constraints of locale handling
> ; there.  The Windows API uses an extension of UTF-16 that includes
> ; unpaired surrogates.  For this, we use a synthetic extension of
> ; UTF-8 called UTF-8of16 that also deals with unpaired surrogates.
> --cut: scheme48/scheme/rts/os-string.scm--
>
>        It also means that the reference implementation given for
>        Scheme48 is invalid (for Scheme48 after 1.3.)
>
>        On the other hand, SLIB provides its `getenv' on top of
>        `lookup-environment-variable' for both Scheme48 1.3 and higher,
>        e. g.:
>
> http://cvs.savannah.gnu.org/viewvc/*checkout*/slib/scheme48.init?root=slib
>
>  > Fortunately, your suggestion (c) is not inconsistent with simple one,
>  > we can leave some rare cases to another srfi.
>
> [...]
>
>