single vs. multi-sexp modules
Alex Shinn
(13 Jan 2006 08:25 UTC)
|
Re: single vs. multi-sexp modules
Per Bothner
(14 Jan 2006 03:01 UTC)
|
Re: single vs. multi-sexp modules
bear
(15 Jan 2006 17:25 UTC)
|
Re: single vs. multi-sexp modules
Alex Shinn
(16 Jan 2006 02:05 UTC)
|
Re: single vs. multi-sexp modules
Jim Blandy
(16 Jan 2006 06:13 UTC)
|
Re: single vs. multi-sexp modules
Tony Garnock-Jones
(16 Jan 2006 11:45 UTC)
|
Re: single vs. multi-sexp modules Alex Shinn (20 Jan 2006 03:08 UTC)
|
Re: single vs. multi-sexp modules Alex Shinn 20 Jan 2006 03:08 UTC
On 1/16/06, Jim Blandy <xxxxxx@red-bean.com> wrote: > > In other words, it leaves it entirely implementation-defined how the > header names are interpreted, and where the referenced files are > stored. I think actually the concern is not so much the filesystem names, as the module names themselves. C at least includes standard libraries such as "stdlib.h" leading naturally to the practice of <short-unique-lib-name.h> The current draft gives us only one example, scheme://R6RS, and it's not immediately obvious how that's supposed to be extended. Do we use scheme://mylib or scheme://myhost/mylib or scheme://myhost/myuser/mycategory/mylib ? Do we include the extension in the path for non-default libraries? Should we use http://... for extensions available on the web? I think perhaps Java is a better and more modern example to take from with an explicit naming hierarchy. It says nothing about how the package names translate to file names, and nothing needs to be said, because once you establish the hierarchy semantics, people on OSes with filesystem hierarchies will just translate that in the natural way. -- Alex