At Fri,  2 Dec 2005 22:17:00 +0000 (UTC), Taylor Campbell wrote:
> Already there has been a great deal of contention over several items in
> this SRFI.  Although I know that this is a very difficult issue to
> tackle, and my initial reaction was reservation about joining the
> discussion, I think there are several ways to significantly improve the
> design of the system.  Some of them I'm sure the authors will disagree
> with, but I'll put them forth anyway.  My alternative proposal and some
> examples of it are available on the web at
>
>   <http://mumble.net/~campbell/proposals/module.text>

Thanks for your thoughts, and for taking the time to put together an
alternative proposal.

The editors looked closely at Scheme48's module design. I'll try to
report the editors' consensus (or at least dominant opinion) on the
issues that you bring up:

1. On the issue of storing source, there is firm opposition to mixing
   any notion of files into the standard. The current proposal can be
   seen as requiring portable code to use an implicit `code' form.

2. The `<language>' part of the library form is present so in the hope
   that we can refine the `import', `export', and library body syntax
   in the future without breaking R6RS-based code. There are other ways
   to achieve the same goal, but declaring the library's language seems
   to be the simplest.

3. On the issue of using `for-syntax' and nested `for-syntax', the
   editors have a bit more work to do. There is a rationale for the
   current syntax, however: it's easier to state --- and maybe easier
   to check --- the constraint that an identifier can be imported from
   only one source, even across phases. (This constraint doesn't exist
   in Scheme48 or MzScheme, but it's a crucial compromise in the
   current SRFI.) Meanwhile, there is significant opposition to the
   idea that a library can be instantiated once for its use in all
   phases. (Compiling a library multiple times is not necessary.)

4. On indirect exports, I'm actually not certain whether it matters to
   have a separate `indirect-export' form instead of bundling the
   information with `define-syntax'. I'll have to get back to you on
   this suggestion.

5. On the issue of separating interface from implementation, there was
   considerable opposition to requiring a separation. Optional
   separation, then, was omitted in the interest of simplicity. The
   current proposal does, however, include a relevant compromise:
   macros cannot expand to `import' or `export', and all imports and
   exports must appear at the beginning of the library, so the
   library's interface is textually apparent.

Reasonable people may disagree on many of these points, and I don't
consider the above to be a refutation of your arguments. But I hope the
above helps explain the opinions (not all mine) that shaped the current
SRFI.

Matthew