On Oct 2, 2009, at 4:06 PM, Derick Eddington wrote:

> I look at the issue like this:
>
> This SRFI needs to support having multiple versions of a library
> stored
> as separate files in the same directory.

I disagree.  More to follow.

> The only way to accomplish that is by having versions in file names.

There may be other ways like having multiple versions in one file.
[I'm not advocating this either]

> It is important to support having multiple versions available so that
> different programs which require different versions can both be used.

But different libraries requiring different versions still cannot be
used together.  At the extreme case, when every program just contains
a call to "main" of some library, you'd still have to deal with this
issue some other way.  That other way, whatever it is, can still be
applied to the situation when you have multiple programs.  However,
this SRFI does not describe that other way that solves the problem;
instead, it advocates the nonsolution of having multiple sets of
libraries all available at the same time and for which only certain
combinations work, and only in an unspecified implementation-dependant
manner.  This is unacceptable.

> If the file naming scheme
> does not support versions, the only way to accomplish running the
> different programs is to manage configuring the search paths used for
> each program so that the correct version is used.

Programs are not the problem.  (If Scheme were an operating system,
then all programs would have to run in the same OS instance; how
would I run many programs that have conflicting sets of imports?)

> We should be able to know what libraries are present, which includes
> knowing their versions because different versions are distinct things,
> ...

Ahem.  The SRFI draft says what amounts to giving the implementation
the freedom to choose what version depending on some unspecified order
of exploring the transitive closure of imports and what happens during
the traversal.  So, if Ikarus traverses the imports left-to-right and
Larceny traverses them right-to-left, we might get combinations of
libraries that can be loaded in one system but not the other.  This is
not good.  I would rather have this SRFI omit all mention of versioning
altogether rather than specify something that's not good [we have plenty
of that already].  If you have a better idea for how to handle versions,
please put it in another SRFI.  I *WANT* all implementors to adopt the
same library file naming convention.  This is making it hard.

> I want to make sure everyone has thoroughly thought about these points
> before sacrificing the qualities of the current draft for the sake of
> not being annoyed by file renaming.

I understand your points, but I disagree.  The way I look at it
is that R6RS's versioning is not good because it has the wrong
granularity. (and yes, I wish R6RS did not include versions too,
and just because R6RS says libraries have version by no means
says that this SRFI has to support them)

Please leave conflicts, dependencies, etc., outside of this SRFI and
keep it focused on mapping library names to file names only.

Thanks.

Aziz,,,