On Mon, 2010-03-22 at 17:29 -0400, R. Kent Dybvig wrote:

> > > 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.

Right, sorry for not being clearer.  The ability to map file names to
library names depends on avoiding those ambiguities.  What I'm getting
at is I'd like it to be possible to organize collections of library
files such that file-name listings are the manifest of the names of the
libraries.  It should be possible to organize searched directories in
any way which might cause ambiguities, but it should also be possible to
take advantage of mapping file names to library names (which requires
avoiding those ambiguities, which is natural for many situations).  If
the unencoded-then-encoded lookup is adopted, it'll be necessary to also
know if file names use encoding or not, which is what I'm unsure of
accepting.

> > 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.

Point taken.  Do you think the SRFI should say anything regarding
resolving library names like (~ ---) and (/ ---) without using the
sequence of searched directories?

> > > 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.

That's the intent.

> 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),

I do not want to do that.

> there's no
> way you can prevent them from being created and used in nonconforming
> implementations.

If nonconforming files use a different name extension, they're easily
distinguished.

> > 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?

Because "sls" fails to accomplish the purpose of adopting a new
extension.  I promoted "sls" because I thought the purpose is that it
uniquely distinguishes an R6RS file type.  But, because of what "sls"
means, it's not appropriate for doing that, hence "r6rs-lib".

> And if it does, why can't other formats or dialects use the same
> extension?

Because that defeats the purpose of file name extensions and causes
problems avoided by using distinct extensions (as mentioned in the
"Dialects, Formats, and Extensions" section).  What's the point of
adopting "sls" if it's used like "scm" or "ss"?  If "sls" will be used
for different file types, I don't see the reason to use it instead of
"scm" or instead of not using any 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.

That's part of the problem.  If the environment variables are named
"SCHEME_" then they're for any Scheme libraries, which means, if "sls"
is ambiguously used, there can be "sls" files which don't conform to
SRFI 103 which will interfere.

> 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.

Why?

> 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.

IMO, that's mostly because of the momentum of ancient traditions (and
maybe superstitions).

What do you and anyone else think of the compromise of using "r6l"
instead of "r6rs-lib"?

> 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).

I thought Windoze and MacOS lost that a long time ago.  Bleh.

> 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.

That's leaning me more towards losing the encoding.

--
: Derick
----------------------------------------------------------------