[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Plan for revising
From: Derick Eddington <derick.eddington@xxxxxxxxx>
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.