[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: five problems with this draft SRFI
- To: William D Clinger <will@xxxxxxxxxxx>
- Subject: Re: five problems with this draft SRFI
- From: Derick Eddington <derick.eddington@xxxxxxxxx>
- Date: Tue, 29 Sep 2009 20:22:26 -0700
- Cc: srfi-103@xxxxxxxxxxxxxxxxx
- Delivered-to: srfi-103@xxxxxxxxxxxxxxxxx
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:from:to:cc :in-reply-to:references:content-type:date:message-id:mime-version :x-mailer:content-transfer-encoding; bh=jXsqqQp5qBxJ1SgzR3LpL5/aQdn6iHOExmhPh8MWC84=; b=DAZJ7+ZhjLBpmphUjVjLEiDSIHruIah5hWyrezm5nJfVo2epdsK+/wweo/phTVK5qg WpHZoHXFUSg1VbhY6eukrOROh7DXea3gGDkS/R8rMvN5XmZmCtfGTwIMfpDfWMZoKCFS 9OL3bZz0W8HQEBHWaXkLisQPRtUydEQNW5FKo=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:x-mailer:content-transfer-encoding; b=Q60gRr6+r70QhVSBsZhLV1EK553X+YjFh1RjhCtyl9nBTaJt1hj8W5/EdSG2d2XX3d Gkcq/+zVhPQsCufRgPKiBvBfk801QWGmTQRthYh8JeJANBZWcVzVc73B4BXzJ/aISmNQ NRyszXdN7I3bDp9S87U/UAhSd/xgk1HZgCIzc=
- In-reply-to: <20791565.807631254275322110.JavaMail.root@zimbra>
- References: <20791565.807631254275322110.JavaMail.root@zimbra>
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
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)?