[I have put extra time into trying to make this email clear, insightful,
and productive.]

On Wed, 2009-09-30 at 09:11 -0400, William D Clinger wrote:
> Derick Eddington wrote:
> > Library references, in the current draft SRFI,
> > always do have a one-to-infinite mapping to file names, because an R6RS
> > version reference, including an empty/non-existent one, always matches
> > versions with more components than in the version reference, and the
> > possibilities are infinite.
>
> I appreciate the clarification.

Thank you for helping analyze this draft SRFI.

> As I predicted in a message sent to r6rs-discuss before
> the ratification vote (but am too lazy to look up right
> now), the version number is being treated as part of the
> library	name, but with special rules that add complexity
> to both the semantics as seen by programmers and to
> implementations.

Do you think versioning should be treated, in any way, as part of the
library name and/or library reference?

Treating it as part of both makes a lot of sense to me.  Version 1.2 of
a library is a different thing than version 0.7.  In natural language,
when we refer to a versioned library, it's normal to call it "Foo 1.2"
because that's the name of that distinct thing, and it's normal to say
"Foo greater than 0.7" when referring to what library to use.

I expect versioning in names and references to be treated with special
rules because the purpose of having versioning in them is to have
special semantics.  Different versions of libraries, and so version
constraints, are reality.  The complexity added by versioning is not
going away, it's just a matter of where it gets pushed to.  I think it
makes a lot of sense to have the language support versioning in the same
way we use it in natural language: as part of the name or reference, as
part of the language, at the syntactic site libraries are named or
referred to.  Until someone convinces me why that shouldn't make sense
to me, I'm going to desire versioning support like R6RS's and desire to
support it in this SRFI.

A personal example: I have built a library (let's call it A, for below)
on top of someone else's library, and their library (let's call it B)
already comes with its own version numbering and I made it into an R6RS
library with the version in the name.  Older versions of it are not
acceptable for my library but would correctly import.  So, I used
version constraints to make only versions great enough acceptable.  If I
were not sure future new series of versions would be acceptable, I could
also further constrain the acceptable versions.  If I did not have
version constraints and only had versions as a non-special part of a
library name, I could refer to only one version which is acceptable.

That does not seem acceptable because of the following possible problem:
library A, which can refer to only one version of library B, is stored
such that it cannot be modified by some user; some library C needs to
use a version of library B different than the version library A refers
to but which library A could have also used; the user needs to use
libraries A, B, and C in the same program; for this case, it is not
acceptable to have two different versions of library B instantiated;
therefore, the user cannot run the program, which could have been run if
only libraries A and C could refer to library B such that a single
version acceptable to both could be used.

The user might be able to hack around this problem by making a copy of
library A and modifying it and modifying the search paths to use it, but
the user probably isn't sure it can use the same version of library B
which library C needs, and even if the user is sure, I don't find the
ability to hack around the problem a convincing justification for why
multiple-version-allowing version constraints in library references are
not needed.

How do you think the above problem should be solved?

> The mapping from library references to file names is
> one-to-infinite, but this draft SRFI still contains
> design decisions and rationales that are based upon
> the utility of one-to-one mappings between library
> names and file names.
>
> I maintain that the one-to-one mapping doesn't really
> exist given the realities of this draft SRFI,

A reality of this draft SRFI is that there is a one-to-one mapping from
file names (possibly with versions) to library names (possibly with
versions), and that this can be utilized.  The utility of single-library
files, whose name exactly represents the name of the contained library,
exists whether or not this SRFI supports R6RS's library names and
versioning.

The draft has such single-library files so that:

* People and programs can analyze a file name listing and from only that
know what libraries and their versions are present and where, by taking
advantage of the one-to-one mapping.

* If we want to find the files which satisfy a library reference
(whether or not we have library references which allow an infinite
number of possible versions), we need to deal with only file names and
we don't have to search through the contents of multiple-library files.

* If we want to do something with a file containing the library with a
given name (possibly with a version), we can one-to-many map the library
name to a bounded set of file names, and know only that library is in a
file with one of the file names.

Thank you for helping me distill these design rationales.  I will revise
the draft to attempt to better convey them.  I apologize for confusing
the issue with less apt wording; I was trying to be very succinct.

> from
> which I conclude that the design decisions and rationales
> based on that nonexistent mapping should be reconsidered.

If it were not proper to consider versioning as part of the library name
and library reference, I'd agree with that conclusion.  But I don't see
why versioning, including version constraints, is not properly
considered part of them, and so not properly part of the file name in a
scheme designed for utilizing single-library files with names which
exactly represent the name of the contained library.

My position has swayed towards being more in favor of the current
draft's versioning support.

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