This page is part of the web mail archives of SRFI 83 from before July 7th, 2015. The new archives for SRFI 83 contain all messages, not just those from before July 7th, 2015.
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