> (I'd like to make a point I didn't.  With file-name extensions
> automatically added, you can't name every possible file via library
> names, because you can't get a file name without a "." and extension.
> Perhaps this could be solved by interpreting an empty-string extension
> as meaning "don't add an extension", but that might conflict with the
> interpretation of an empty-string extension as meaning "include
> system-default extensions", unless you add more special rules about
> where the empty-string extension occurs.)

Indeed.  This is why an extension in Chez Scheme's list of extensions
includes the "." (if the programmer wants one).  It would be great if the
SRFI would go the same way, so that I don't have to support both forms.

> I think such unencoded-then-encoded lookup would work.  I'm going to
> explore adopting it, and I'll get back to here about that.

Good.

> However, it breaks mapping library-file names to library names, which
> has been one of my original goals for this SRFI, because, e.g.,
> acme/a%3A%b.ext might be (acme a%3A%b) or (acme a:b), and
> foo/bar/zab.ext might be (foo/bar/zab), (foo bar/zab), (foo/bar zab), or
> (foo bar zab).  Being able to programmatically manage/analyze
> collections of library files (as far as what's possible from knowing
> only library names) from only file-name listings has been important to
> me.

I suppose the rationale for wanting this is in SRFI 104, but I haven't
looked at that SRFI yet.  But there's already ambiguity inherent in the
SRFI 103 mechanism.  If foo/bar/zab.ext is in /home/users/bob/libs, it
might already hold libraries (zab), (bar zab), (foo bar zab), (libs foo
bar zab), (bob libs foo bar zab), (users bob libs foo bar zab), or (home
users bob libs foo bar zab).  If /u is a link to /home/users, it might also
name (u bob libs foo bar zab).  Other links add other possibilities, and
you can't generally enumerate what they are because the links might exist
on external filesystems!  Allowing encoded and non-encoded forms of a name
just adds another dimension to the ambiguity.

> I'm not sure it's the SRFI's place to involve special handling of
> (~ ---) or (/ ---), (c:/ ---), etc.

Perhaps not, but I'm sure it's my place not to implement a SRFI that
inhibits access to such files.

> > Incidentally, is there a reason to chose "r6rs-lib" as the extension for
> > R6RS libraries rather than the shorter "sls" as recommended in the R6RS
> > non-normative appendices?  We selected sls because it did not (to our
> > knowledge) conflict with existing extensions for Scheme source code, so I
> > assume that's not your reason.  If there is no particular reason why you
> > chose r6rs-lib, please change it to sls.
>
> I can't find "sls" in the Non-Normative Appendices nor any of the other
> R6RS documents.

Sorry---that was in an earlier draft but was later removed.  Even though
it was removed, it has been the extension of choice for r6rs libraries,
and it's more pleasant than r6rs-lib.

> I do have particular reasons for choosing "r6rs-lib".
>
> "sls" is currently being used for single-library and multiple-library
> files.  If "sls" (or any extension) is used for different types/formats,
> we can't programmatically process files based on their name extensions
> because they could be something unknown.  "r6rs-lib" says precisely what
> a file is: one R6RS library.  "thing-libs" means a file containing
> multiple libraries of dialect Thing.

With the current SRFI draft, r6rs-lib can and will be used for
multiple-library files as well.  While the SRFI says an implementation
must support files with an r6rs-lib extension that have a single library
as the first datum, it doesn't say that an implementation must not support
files with an r6rs-lib extension that contain multiple library forms.  If
it did, I'd be trying to change that, because I see no reason to disallow
programmers from putting helper libraries in the same file as the library
directly imported from a program.

There's no reason you can't just change "r6rs-lib" to "sls" and make
exactly the same statement.

Kent