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.
On Wed, 2009-10-07 at 13:43 -1000, Shiro Kawai wrote: > I'd like to clearify one point. Suppose I have /usr/share/scheme > and /home/shiro/scheme in SCHEME_LIBRARY_PATH, in that order, > and I have those files: > > /usr/share/scheme/acme/foo.sls > /home/shiro/scheme/acme/foo.sls > /home/shiro/scheme/acme/foo.myscheme.sls > > If myscheme wants to import (acme foo), should it load the > "first match" which is /usr/share/scheme/acme/foo.sls, or > should it keep looking for the "best match", which is > /home/shiro/scheme/acme/foo.myscheme.sls? I think the first match should be required to be chosen. I think this issue is important because the ordering of the search paths should support overriding/overlaying library files to be used instead of those in latter search paths, and you'd need to be certain what files will be chosen. (I was aware the current draft made it uncertain, and I didn't like that.) > 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".) > I wonder it may introduce a subtle > incompatibilities among different implementations which can be > a source of problems difficult to track down. Yeah, it would introduce such issue. 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? > 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. -- : Derick ----------------------------------------------------------------