This page is part of the web mail archives of SRFI 103 from before July 7th, 2015. The new archives for SRFI 103 contain all messages, not just those from before July 7th, 2015.
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. --shiro