On Fri, 2009-10-02 at 19:02 +0300, Abdulaziz Ghuloum wrote:
> 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]

(Right.  I was assuming the assumptions of the current draft.)

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

The idea was to leave it open similar to how other aspects of Scheme are
left open.  But an aspect needs to be evaluated individually for whether
that is appropriate.

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

That's an excellent point, and enough to kill my argument about
different programs.

> 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 thought having the file naming scheme support R6RS-like versioning
would assist broader adoption because I've been under the impression
some Scheme systems' implementors and/or communities are more in favor
of it and would want it in file names for all the reasons I've
enumerated.  I'm not familiar enough with all these communities to make
the best assessment, but I had to make a decision about what to throw
out here as the draft to be discussed.

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

If R6RS library names include a special version component, then that
component is directly relevant for consideration of its inclusion in
this SRFI.  Which brings in all the aspects of R6RS versioning which
interface with having versions in the file naming scheme.  These things
are obviously controversial and obviously not figured-out enough.  So,
I'm now convinced it's the right decision for this SRFI to ditch all the
versioning.

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