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 30 Sep 2009 03:22 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
----------------------------------------------------------------