[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Plan for revising

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