On Mon, 2010-03-15 at 10:09 -0400, R. Kent Dybvig wrote:

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

Okay, I'll adopt that, with the restriction that "." occur only as the
first character, to avoid the conflict mentioned in the current draft.
(The SRFI previously encoded "." to avoid the conflict, and that was
changed in favor of not encoding it, disallowing it in extensions, and
using "system-ext" extensions instead of "system.ext".)

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

The Design section of SRFI 103 says:

        This SRFI supports files which each contain only one library.
        This supports one-to-one mapping library-file names to library
        names, which supports knowing what libraries are available and
        where they are located, from only file names.

That is useful to humans reviewing/navigating collections of library
files and is useful for programmatically working with library files
without needing to read file contents (maybe the contents are
accidentally malformed but the processing doesn't care, or maybe you
don't have access to the files and are dealing with only a package
manifest).  SRFI 104 is intended to provide ready-made helpers for
working with library files.

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

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

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.  Maybe there
should be some brief language saying that systems may have special
handling of library names they consider special?  I'm seeing this issue
as one of those things which should be intentionally left-out because it
complicates the specification with exceptional rules and is so dependent
on particular platforms, and so should be left to informal conventions.
But I'm open to changing my mind if it can be included smoothly (I know
that's vague, I need a clearer idea of how that could be done).

> ["sls"] has been the extension of choice for r6rs libraries,

I feel largely responsible for that, and after concluding that
"r6rs-lib" is superior, I feel responsible for rectifying the situation.

> and it's more pleasant than r6rs-lib.

("More pleasant" is subjective.)

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

The intent is that "r6rs-lib" will not.

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

The current draft says: "files conforming to this SRFI have one library
per file", and "extensions used for library-file names are encouraged to
precisely and unambiguously denote file types".  I think you're right,
for my intent for "r6rs-lib", I should require that "r6rs-lib" files can
have only one library.

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

I don't want to inhibit systems from supporting multiple-library files.
For specification/implementation simplicity and for mapping library-file
names to library names, this SRFI specifies single-library file formats.
Multiple-library files just won't conform to that aspect.  I want
different file formats to have different extensions, so
multiple-R6RS-library files might use "r6rs-libs".

How do you think multiple-R6RS-library files should be handled?  Like
Larceny, or something else?  E.g., not a bottom-up tree search like
Larceny, but something like: if multiple libraries are in a file located
according to this SRFI's current method they're all loaded; which means
a primary library can have its helpers occur first and they'll be
available for it, but helpers cannot be located if imported from a
library outside the file because they're not in a file which can be
found via their library name?

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

That doesn't address my other reasons for choosing "r6rs-lib".

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

What extensions do you think other formats/dialects should use?  (If
they don't use distinct ones, there are problems and they're not nearly
as useful, as mentioned in the current draft.)

When the SRFI previously used "sls", I felt compelled to name the
environment variables with "R6RS_" prefixes, to avoid having other
dialects using "sls" interfere with locating the SRFI's "sls" files.
But that's not as useful as one searched-directories configuration which
can work for multiple formats/dialects, and I was given the impression
that people want the environment variables named as "SCHEME_".

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