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)
|
>From: Derick Eddington <xxxxxx@gmail.com> Subject: Re: five problems with this draft SRFI Date: Sat, 26 Sep 2009 19:38:06 -0700 > 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. Version numbers aside (which I feel ambivalent), limiting single-library files *in this srfi* doesn't hurt, I think. Later we can come up another srfi with multi-library file, attaching different suffix (*.sla for Scheme Library Archive?). My only concern is that this path suspiciously seems similar to Java's *.class and *.jar files... --shiro