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



I've recently started work on a new clang environment, Archimedes. A
more detailed documentation is to follow, but here's what this is all
about, in a nutshell.

The project is basicly continuing Rauli's and my work on a procedural
clang framework (our joint work was called Anaximenes), born from what
Tuomas and I discussed about clang compiling and optimizing. Archimedes
itself is a system for performing function calls and writing procedural
abstractions. That is, you can a) tell Archimedes (from Java) to execute
a given ZZCell (which, of course, needs to be a valid Archimedes
"program"), and b) compose Archimedes functions from primitives and
other Archimedes functions. Archimedes is meant to support a wide
variety of imperative-like programming paradigms, including:
* simple imperative programming,
* procedural/structured programming,
* object-oriented programming,
* functional programming.
On the other hand, Archimedes will not support e.g. logic programming,
because there you don't specify things to be executed, but rather
constraints for these things. That's outside the Archimedes framework
(although Archimedes programs should definitely be able to interact with
declaratively written programs). Archimedes itself is not supposed to be
very intelligent, it should only be the framework to hold everything
together. Archimedes has no control statements like for() etc. -- these
should be implementable as primitives or functions.

At the heart of Archimedes are hierarchically cascading expressions in
the style of ordinary programs, or mathematical expressions. A function
declaration, then, is just saying "f(a, b, c) is defined as (a*b)+c" or
some such. Other than Rauli's and my earlier Anaximenes work, Archimedes
will not support overloading within the language. However, overloading
is easily constructed for specific functions by putting a case-kind of
statement into a function as the operator in the top-level expression.
Then, all the definitions for the function can be on a rank like in Anaximenes.

The whole system centers around the (not yet realized) concept of
"cached compiled objects," meaning that some objects are compiled
on-the-fly and cached in the usual GZZ cache (which is something else
not implemented yet); any change to the "source" in the ZZ space would
invalidate the cached version, causing re-compiling or interpretation.
(System stuff changes to which could cause crashes would have to be
locked inside the space somehow.) This means Archimedes will be a
completely reflective system. Efficient compilation should be
facilitated through an optimizer system that will take specifications
from the programmer connected to the code within the ZZ space. (For
example, we were talking about saying things like "store this rank of
cells as an array of integers". Okay, that's not the most sophisticated
thing we'd like to do ;o) )

Some of the goals I try to keep in mind while working on the
system/implementation are:
* extensible to compile efficiently later, without changes in the semantics
* debugable
* supporting various programming paradigms, calling conventions etc.
* everything primitives can do (like for() loops), functions should be
able to do, too
* freedom in how function arguments are structured in ZZ space
* useful visualizations, especially in connection with the zaubertrank
* applicability of mathematical proofs to Archimedes programs (this is
important in optimizing, cf Don Knuth's comment about optimizing in
_Literate Programming_).

I do hope that this effort will actually go somewhere. ;o)
- Benja