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 Tue, 2009-09-29 at 21:48 -0400, William D Clinger wrote: > By the way, my remark about the one-to-infinite nature > of the mapping from library names to file names assumed > that implementations were supposed to search all of the > potentially infinite file names whose version numbers > might match. From your remark that the mapping is only > one-to-many but not one-to-infinite, I infer that systems > don't have to search for file names that include version > numbers, but I'm not certain of that conclusion. Please > advise. Haven't you meant library references and not library names? In the current draft SRFI, a library name with a version maps to a file name with the same version. This is one-to-many because of multiple search paths, the implementation-specific file name extension, and the implicit file name. If it weren't for these, it would be one-to-one. Library references, because of their version references, in the current draft SRFI, can have a one-to-infinite mapping to file names. Yes, this requires searching through all the theoretically possibly infinite file names which might match. This searching is done by listing the entries in the directories where matching files could be, and filtering-out the non-matches, and possibly sorting the matches according to the ordering of the current draft. Isn't it okay to assume directories can be listed? Because there is not going to be, and cannot be in limited file system storage, an infinite number of files matching a library reference, and because the number of matching files is in practice not going to be large, and because the number of non-matching files which must be filtered-out is in practice not going to be large, isn't it okay to take advantage of the ability to list directories and find matches? In my tests with the reference implementation of SRFI 104, the cost of this directory listing, filtering, and sorting has seemed acceptable. This is an important issue, and if the cost really isn't acceptable, then I guess I have to abandon the current design. But I find it hard to believe that, in the year 2009, I still can't take advantage of listing directories, and I'm not giving it up easily. Additionally, multiple libraries per file has the cost of searching through the contents of theoretically-infinitely-long files in order to find matches. It's unlikely in practice that bad-case scenarios will happen, but it's theoretically possible. If that's acceptable, why isn't searching through directory listings acceptable (assuming you think it's not)? -- : Derick ----------------------------------------------------------------