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: Sat, 03 Dec 2005 14:33:34 +0100 From: Michael Sperber <sperber@xxxxxxxxxxxxxxxxxxxxxxxxxxx> But anyway, your concern is a very valid one. Here's what I think we came down on: - The current proposal doesn't preclude a future extension for optionally specifying more static information about the names being exported, as is possible, for instance, in Scheme 48 or Bigloo. It does, though, make it difficult to extend in the current syntax in a way that bear wants. Grovelling through the source to libraries is not an option, but currently the EXPORT syntax is embedded in the library bodies. My proposal, and Scheme48's module system, would make such an extension even easier and in a satisfactory way for the conditions bear would like. - Any such extension is bound to provide only incomplete static information about the thing being exported, and thus preclude certain kinds of optimization. - A type language (or flow language or whatever) would be a topic for active research, which I don't think we were prepared to do. - Consequently, highly optimizing compilers (like Chez Scheme, for example) really need to look at the entire source code of the everything you're importing (or some representation thereof) to do a good job. This is true for heavily optimizing compilers, but I don't think bear was referring to them, particularly since (in response to the first point) all compilers that do not perform whole program analysis lose information anyway. Knowing exactly what identifiers have run-time variable denotations and what identifiers have syntactic denotations is enough to know how to compile the code (see below on how to deal with macros). Actually, the current SRFI doesn't even provide enough information for that, but my alternative proposal & Scheme48's module system both do. Moreover, separation of interface from implementation would allow interfaces to include specifications of properties that implementations must support, if such flow languages were developed. - Macros require you to have some representation of the source code of the library you're importing anyway. (Some people might argue this is a design mistake in the library syntax---several people are working on macro/module systems that don't have this property. But once again, (very) active ongoing research, not ready for R6RS.) This is true (except I don't see why you need the source code and not just any representation of the code, source or compiled), but bear's situation and requirements are still useful for all of the cases where macros are not used; macros would only imply points of synchronization in the distributed compilation where the compilation of one module would simply wait until another module, from which the first imported syntax, finishes, to access the macros from it.