[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Independent optimizing compilation [was: fundamental design issues]

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.

bear <bear@xxxxxxxxx> writes:

> 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

You're kidding, right?  (Unless you mean "most" = >50%.) :-)

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.

- 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.

- 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.)

Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla