[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Independent optimizing compilation [was: fundamental design issues]
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
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.