five problems with this draft SRFI William D Clinger (26 Sep 2009 01:20 UTC)
Re: five problems with this draft SRFI Abdulaziz Ghuloum (26 Sep 2009 05:58 UTC)
Re: five problems with this draft SRFI Derick Eddington (26 Sep 2009 15:42 UTC)
Re: five problems with this draft SRFI Derick Eddington (27 Sep 2009 02:43 UTC)
Re: five problems with this draft SRFI Shiro Kawai (27 Sep 2009 03:16 UTC)
Re: five problems with this draft SRFI Derick Eddington (29 Sep 2009 02:32 UTC)
Re: five problems with this draft SRFI William D Clinger (30 Sep 2009 01:49 UTC)
Re: five problems with this draft SRFI Derick Eddington (30 Sep 2009 03:22 UTC)
Re: five problems with this draft SRFI Derick Eddington (30 Sep 2009 03:51 UTC)
Re: five problems with this draft SRFI Derick Eddington (30 Sep 2009 06:33 UTC)
Re: five problems with this draft SRFI William D Clinger (30 Sep 2009 13:11 UTC)
Re: five problems with this draft SRFI Derick Eddington (01 Oct 2009 09:10 UTC)

Re: five problems with this draft SRFI Derick Eddington 27 Sep 2009 02:38 UTC

On Sat, 2009-09-26 at 08:42 -0700, Derick Eddington wrote:

> [...]

> With the current draft of SRFI 103, the number of paths where a library
> reference's file might be satisfied from is:
>
> (* 4 number-of-search-paths)
>
> because for each search path, a library's file might be located at four
> possible sub-paths: 1) no implicit file name and no
> implementation-specific file name extension, 2) no implicit file name
> and an implementation-specific file name extension, 3) an implicit file
> name and no implementation-specific file name extension, and 4) an
> implicit file name and an implementation-specific file name extension.

I was wrong.  With the current draft of SRFI 103, the number of paths
where a library reference's file might be satisfied from is:

(* 4 number-of-acceptable-versions number-of-search-paths)

and number-of-acceptable-versions might be infinite.

I should revise this SRFI to talk only about the main reason it has
single-library files: to have library file path names exactly represent
the name of the contained library.

Even though the current draft has a one-to-infinite mapping of library
references to path names (because of versions), in practice, when a
person is trying to find the file containing a library, I think it's
better to be able to find it by only looking at a listing of path names
instead of also having to open and search through files which might have
multiple libraries.

I think the ability to analyze a listing of the path names under a
directory tree to know the names of all the libraries located in that
tree is worth having single-library files.  That analysis is
accomplished by recognizing the .sls extension and mapping .sls path
names to library names.  I believe this is worth designing for because
then people and programs can look at only a listing of path names and
know all the libraries, the actual file contents are not needed, and an
additional "manifest" file correlating files to contained libraries is
not necessary.

--
: Derick
----------------------------------------------------------------