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)
|
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 ----------------------------------------------------------------