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

Re: five problems with this draft SRFI

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