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 18:21:57 -0800 (PST) From: bear <bear@xxxxxxxxx> But I want to point out some simple things that work in other languages, and point out that this model does not support them. (I'm going to assume, since you're responding to my mail, that by 'this model' you mean my (Scheme48-based) model, not the current SRFI's (MzScheme-based) model.) In static languages such as C and Pascal, a forward declaration is often used to state particular properties about a function or procedure, while leaving the body of the definition for later (presumably after the definitions of some of the things it depends on). In both languages, a procedure or function may have any number of forward declarations (or the same forward declaration may be imported multiple times) but only one definition. In C in particular, this turned out to facilitate a very useful pattern. A "header file" with nothing but forward declarations allows most interdependency problems to be solved statically, because the forward declarations facilitate the separated compilation of many different units. The effect is that with the forward declarations handy, the compiler knows how to compile calls to particular functions, even when the definitions of those functions are not visible. This is very important. I certainly agree that this can be very important, and this is why I am proposing a module model that allows for this kind of information to be obtained from simple static analyses of the module language without delving into the source code of any modules. So I look at the "imports" syntax, and I am thinking, "Here is a forward declaration. Does it contain enough information to allow a compiler to create an optimized call to the associated function without being able to see the function definition?" And the answer is a resounding no. It contains only namespace control information. No, the answer is not a resounding 'no.' The answer depends on what information can be obtained statically from the modules from which bindings are being imported. In my proposed model, this information is *always* available to a processor of the module system, in the form of the interface of the module. Indeed, namespace control information is only one of the many useful properties of the model I'm proposing, among which this kind of easy static analysis of module descriptions also lies. So I look at the "exports" syntax, and I am thinking, "okay, here is more namespace control information, but it is also a specification that, together with the file of source code, may be used to automatically generate (implicit) forward declarations usable in the compilation of other files." Ignoring macros, you do not need the source file. The interface contains enough information to know what kind of denotation every identifier exported by a module implementing the interface will have. This is sufficient to compile clients of the modules (assuming, again, that macros are not used, which inherently require static information to be passed across module compilations). In the simplest form, there is no more information than whether the binding is a syntactic binding or a run-time variable binding, but the EXPORT syntax could be extended to support more information than that for further compiler optimization. In Scheme48, for example, there is a simple static type language that can be used to annotate the identifiers listed in interfaces with their static types; the interface of the SCHEME module, for instance, might be defined along these lines: (define-interface scheme-interface (export ... (car (proc (:pair) :value)) ...)) (This optional static type language is documented in my unofficial Scheme48 reference manual, which is available on the web at <http://mumble.net/~campbell/darcs/s48-refman/> (Texinfo source; I can supply different formats on request).)