> > But there's already ambiguity inherent in the
> > SRFI 103 mechanism...
>
> I've been aware of that.  Programmatically-processed library-file names
> need to be relative to their searched directory, which is a natural
> approach.  SRFI 104's specification of 'library-file-name-info' mentions
> this.  E.g., when programmatically working with collections of library
> files, you change the current directory to searched directories and then
> work with the recursively-listed file names.  I do that often.

I don't understand what you're getting at.  If you find the file via the
library name and the search path, there's no problem with either encoded
or unencoded pathnames, but you're talking about going the other way.  If
you find the file via some other mechanism, e.g., listing the directories
specified in the search path, ambiguities can occur with both encoded and
unencoded pathnames.  The ambiguity arises if one directory in the search
path is a subpath of another or if two of the directories link to the same
place.

> I don't want the SRFI to inhibit it.  I meant I'm not sure it's the
> SRFI's place to specify or require the special handling.

There's nothing special about unencoded pathnames or about requiring
implementations to look first for a file named by the unencoded pathname.
On the other hand, encoded pathnames _are_ special.  If you don't want to
require special handling, don't require encoding.

As you suggest, you could just allow implementations to look first for a
file named by the unencoded pathname without requiring them to do so.
It's not as useful, but at least it doesn't prohibit implementations from
supporting access to arbitrary files.

> > With the current SRFI draft, r6rs-lib can and will be used for
> > multiple-library files as well.
>
> The intent is that "r6rs-lib" will not.

Yet, unless I missed it, SRFI 103 does not specify that implementations
must reject files that contain multiple libraries, only that a conforming
file contains one library and that a conforming implementation must
support such files.  That's a good thing, since it allows conforming
implementations the freedom to support files that don't conform, for
whatever reasons.  Even if you were to require implementations claiming to
support SRFI 103 to reject files containing multiple libraries or even
forms other than library forms (which I hope you do not do), there's no
way you can prevent them from being created and used in nonconforming
implementations.

> How do you think multiple-R6RS-library files should be handled?

I would not try to standardize on that at this point.

> Why should the SRFI's R6RS library file format get "Scheme library
> source", when other formats or dialects are also Scheme library
> sources?

Why should the R6RS library file format _not_ get sls, which is nice and
short?  And if it does, why can't other formats or dialects use the same
extension?  You don't really need for arbitrary files using the sls (or
any other) extension to conform, just for the ones you happen to find via
the search path and want to manipulate in certain ways.  Yes, by choosing
an unusually specific and long name like r6rs-lib, you can be fairly sure
no one will use the extension for some other purpose, but I think an
eight-character extension is too high a price to pay.  I think I'm not
alone, since most of the filename extensions people have chosen over the
years range from one to three characters in length.

On the other hand, if you do require (against my advice) to require SRFI
103 implementations to reject files containing something other than a
conforming library, I hope you keep the r6rs-lib extension and limit the
damage to files with an r6rs-lib extension so that others can use .sls
files in those implementations without such a restriction.

BTW, I don't think I saw in the discussion what you intend for the SRFI to
do about the case of the letters in a library name.  Windows filesystems
in are case-insensitive, as are MacOS X filesystems (at least optionally).
So what happens if one has two libraries whose names differ only by case?
I do so hope that you don't end up requiring encoding of either upper- or
lower-case letters, but that seems to be the only solution that would be
compatible with your perspective.

Kent