>From: Derick Eddington <xxxxxx@gmail.com>
Subject: Re: Plan for revising
Date: Fri, 09 Oct 2009 14:31:13 -0700

> On Wed, 2009-10-07 at 13:43 -1000, Shiro Kawai wrote:
> > The current wording of srfi-103 seems to leave it implementation
> > dependent.  Is it correct?
>
> That's correct.  The only reason for that was because of what I was
> thinking the current draft should be if versions are in file names (more
> below).  All the versioning-related stuff will be removed in the next
> revision.  The next revision will say something like: "Scheme
> implementations must choose the first-ordered match.".  (I should have
> mentioned this in my "plan for revising".)

Thanks for the clearification.

> I wonder if the ordering of an implicit file name match relative to a
> non-implicit file name match, within the same search path, should remain
> specified, instead of becoming unspecified in the next revision as Aziz
> suggested, because it's short and simple to specify and because then all
> cases are covered.  I understand this case happening is probably always
> accidental, but if it's easy to cover it and have complete coverage of
> all cases, then why not?

I'm for specifying the case as well.  It's arbitrary, but I don't
see the benefit of making it unspecified (it doesn't make some
clever optimization possible, does it?), while being unspecified
does introduce ambiguity and incompatibilities among implementations.

> > The current
> > srfi-103 says something about transitive imports; could you
> > explain it a bit more?
>
> My thinking was that implementations which desire to do more involved
> combined version constraints handling (such as, as the imports and their
> transitive imports are processed, determining some "best" version, or
> trying to fix conflicts by backtracking and trying different versions)
> could use the current draft's ordering as part of their algorithm for
> the more involved handling.  What match is chosen was not specified so
> that implementations could choose anyone as determined by their more
> involved handling.

Thanks for the explanation.  I think it's good that we don't deal
with versioning stuff any more.  Some sort of version handling is
necessary, for sure, but I guess it won't be too late to decide how
after we build enough experiences in each implemenation.

--shiro