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.
Date: Fri, 2 Dec 2005 22:04:03 -0700 From: Matthew Flatt <mflatt@xxxxxxxxxxx> 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: Thanks for the speedy response. I hope that the individual editors will elaborate on their own opinions, but in the meantime I'll briefly respond to these points: 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. I'm a bit confused, if this is the case, about how libraries can use other libraries in practice if there is no way to refer to them other than by some unspecified URI convention. Surely some notion of resources containing Scheme source is implied by the relative URI naming mechanism for other libraries; why couldn't this be applied equally well to what I (& Scheme48) call FILES clauses? 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. Do you expect to be changing the module system dramatically in the near future after finalization? I think that this use of the language device conflates two separate issues, the module language and the source code language, which should be managed in different ways. A SCHEME (or SCHEME-R6RS, or (SCHEME R6RS), or whatever) module/library is a simple way to manage the latter; if you really want to include information about the module language revision, why not include something at the top of the file, like (R6RS) or something? Is it useful to be able to use dramatically different module languages within a single set of modules? One useful property of having the Scheme language module hold regular status among other modules is that its interface can be transformed as with any other modules. Aubrey Jaffer's concern about shadowing standard Scheme identifiers would be easily answered in this way; for example, a module that uses Jaffer's commutative ring library might be defined like this: (define-module my-module my-module-interface (import (modify r6rs-scheme (hide + * / - zero?)) commutative-rings ...) ...) 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.) I'm a bit unclear on this constraint you mention; could you explain it in a bit more detail? 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.) This was the point I had in mind when I mentioned that the SRFI authors would probably disagree with me. I've read the paper, and I see in section 3.3 (Phase Separation) *that* the MzScheme module system executes every module for every phase at which another module uses it, but I can't find any explanation of *why* that is. The need for the separation of the lexical environment is obvious, but why could not two phases' lexical environments refer to identical modules (i.e. the same, single instantiation of one module)? I'll agree, of course, that in any actual software system modules will be instantiated more than once for their existence in the universe, but I'd like to understand why they are mandated to be instantiated for every phase at which every other module's instantiation uses them. 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. OK. I'm not sure whether I mentioned this already, but Scheme48 gets by with the auxiliary name list (or indirect export list, whichever term is preferred) being specified in each macro's definition, which makes it possible for the SYNTAX-RULES macro transformer to generate the list itself and not need it specified elsewhere. The need to specify the auxiliary names explicitly in psyntax's module system has always bugged me. 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. I'm curious to know why there was opposition to separation. One of the important properties of my proposal, though, is stronger than the 'textually apparent' nature of libraries' exports in the current SRFI. Not only is it textually apparent separately from the library's body, but you don't need to look at the expression or file containing the body at all: all you need are the module descriptions. bear's point here is relevant, as is the point that code embedded in module definitions is fundamentally incompatible with reader extensions, which I'd like the module system not to preclude.