3.1 L structure

L' compilation process is composed of several parts:

• The `Parser', that takes the buffer of characters and converts it into a tree of forms, the abstract syntax tree. The input of the parser is what is called “L”; and the parser acts according to the L concrete syntax.
• The `Expander', transforms the abstract, high level forms into concrete, low level ones. It is responsible for macro expansion. It is also called `Malebolge compiler', because the parsed L forms are called Malebolge. Malebolge deals with the abstract syntax of the language.
• The `Code generators', take the low level forms and transform it into output. It is highly dependent of the output; we could consider that there are in fact several code generators, and these are called `backends'. It is also called `Cocytus compiler', because the low level forms are the Cocytus language. Cocytus deals with the precise semantics of the language.

Malebolge is a bit to Cocytus what C++ is to C: a super-set of the language, that allows more abstraction, more hiding of informations. But reading C++ code, one cannot exactly says what will be executed; by contrast any experienced C programmer knows exactly what's going on when he reads a C program. This is exactly the same thing for Malebolge and Cocytus: reading a Malebolge program provides a global understanding of the program, you can read the intention of the programmer, understand the algorithms. Reading the Cocytus transformation, you can read how this intention was transformed by the Malebolge compiler, and how it is translated into machine language.

Malebolge programs can be converted to Cocytus : both languages coexists. This is important, because it allows a programmer to manually check what's going on in its program, AND to have precise control over the language. So in L, we combine both advantages. Separating the language into two levels renders easy both the global comprehension and deep comprehension of a program.

We already have a complete compilation process that takes L source code, parses it, expands it, and generates x86 code dynamically in memory (that's why the compiler is interactive).

The following (outdated) diagrams shows how the complete L implementation could look like:

     
                        L source file (.l)
                               |
                            parser* (produce L forms)
                            /  | \
        parsed file generator  |  sexped file generator
                          /    |   \
           L parsed file (.pl) |    L sexped file (.sl)
                               |
                               |
                         Malebolge compiler*  (produce L Cocytus forms)
                           /   |     \     \------------------\
     L cocytus source generator |    L slim binaries genetor    \
                         /     |       \                        GNU C generator
                        /      |      L binary file (.bl)           \
      L cocytus source (.cl)    |                                   C output file (.c)
                               |
                          Cocytus compiler* (calls the backend functions)
                        /      |         \
                       /       |          \-------\-----------------
                      /   dynamic x86 code*        \                \
          L GCC frontend                       ANSI C generator      \
                    /                                            L header files (.lh)
                  GCC
                  /  \---------------
                 /                   \
             assembly file (.S)   object file (.o)
     

*: already implemented

• Cocytus
• Malebolge