> No, because file-name strings are inherently platform specific.  Library
> names (for portable libraries) are supposed to be completely abstracted
> from any platform, and that's why I'm convinced allowing them to be
> determined by the flaws of platforms is unacceptable.

I don't want to push the analogy too far, but library names (like strings)
are platform independent as long as they are internal to a Scheme system.
They become platform dependent (like strings naming files) as soon as you
try to tie them to a file system, which is what the SRFI is all about.

> That's not portable and SRFI 103's purpose is supposed to be portability
> across prevalent OSs, so it's not supposed to be concerned with that.
> That can be portably accomplished with libraries named like
> (personal ---) and (for unixes) placing the "personal" directories in
> home directories and doing
> SCHEME_LIB_PATH=$HOME/wherever:$SCHEME_LIB_PATH.

The SRFI's purpose is portability, but it shouldn't prevent the naming of
other files in import forms.  In particular, it shouldn't prevent a
programmer from (unportably) specifying ~/.myappinit, but the proposed
encoding requirement does just that.  Your proposed workaround is
cumbersome and not very unixy.

(BTW, I'm thinking of creating a SRFI that specifies that ~ be treated as
it is by most shells, at which point ~/.myappinit will become portable, in
the sense that anything defined in a SRFI and not in a revised report or
standard is portable.)

> Actually, the joining of relative library-file names with
> searched-directory names is what prevents that (assuming I'm
> understanding what you mean).  Without the encoding, a library named
> (/ foo), with SCHEME_LIB_PATH=/exploit, will be found
> at /exploit///foo.ext.

That's true with the SRFI as defined, but it is common to ignore search
paths when absolute pathnames are used, so (/ foo) should be found in /
and (c:/ foo) under Windows should be found in c:/ no matter what the
search path contains.

The cause of our differing views on encoding might be a difference in
perspective regarding the purpose of library names.  From my perspective,
library names serve as an abstract way of specifying file names, which is,
in fact, one reason why they are structured as they are.  There shouldn't
be any restriction on the file names we can specify with a library name,
and there's no need to be able to specify file names that don't exist.
For libraries intended to be used on two or more platforms, there's no
need to be able to specify file names that don't exist on both.

Kent