[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: Sat, 26 Sep 2009 19:38:06 -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=zzE2ep1CAhcG6f56j4qBYHIYE/F0yV1BLzvotkjB48Q=; b=B8ulIqu49kM0ujezSDoWD/5kFJd3AWzQf8wOqm2dtXL+63HBW0WH+vxYSb6Q+8sOxQ hroSHScu9FmGHQo55VPLlmaDv+kk7GH6GqD1iIquBKB2EuslWz7/8Z1cnnB+7zEsnnow E8W4kBmO7tdlgf0zyxDQbOu1/CTGobJg9wsFg=
- 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=Yr2npTE6ZvvwOtwbWE+Trhx+MRo16BIp+hK4ztoOVMcun18l3/DmlXJdjWB1cjdeEL aBgjuL1evCk+LBvKFL09hHXPr5QYtKynpWOyiAwPjbQWZ+Pkxhed9LcBjj+hhZMt0x7R lp5OchMhk2tqg0KAo6kIuc2UXDrade83ehfrc=
- In-reply-to: <1253979769.16567.49.camel@eep>
- References: <17415962.765291253928000711.JavaMail.root@zimbra> <1253979769.16567.49.camel@eep>
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
----------------------------------------------------------------