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