[PROPOSAL] Gobo Eiffel Interpreter

[gchauvet]

I would discuss about the ability to add a Eiffel interpreter to Gobo Project and how it would be possible to implement it, by using libJIT library for example.
This project can be reused by getest, by removing the C generation & compilation processes.

[ebezault]

I think it's possible. The Gobo compiler code has been designed in such a way that the code generation is independent from the code analysis/validation. So currently we have class ET_C_GENERATOR which traverses the analyzed and validated code found in the AST and generates C code. But it's "easy" to add other target generators. You mention libJIT as target. I also had in mind LLVM, and also another C generator whose generated code would be less compact/optimized but more modular (to be used to compile libraries as opposed to a full system).

To come back to the possibility to have an Eiffel interpreter. I thought about that during the last 2 decades. But didn't have time to really work on it. You mention libJIT, but when I first started to think about it, all that did not exist. What I had in mind was that the interpreter would analyze the code as needed and execute it on the fly instead of generating some target code. That solution is possible as well.

I'll take this opportunity to mention what I plan to work on in the next few months.
Currently I'm finishing converting the last Gobo library (XSLT) to void-safe mode.
Then I will work on the gec/gelint to be able to compile code in void-safe mode (there is already some work done, but it's not complete).
Then I will improve gelint so that it uses less memory. At work we use gelint to validate our Eiffel classes. We have 22,000 classes, and gelint analyzes them much faster than EiffelStudio. But processing 22,000 classes makes gelint use more than 3 GB of memory. Sometimes we want to run several gelint executions at the same time, but we reach the memory limit. I have some ideas that I want to experiment to reduce the memory usage of gelint.
Enough to keep me busy for some time...

[gchauvet]

Thank you for your feedback, I will take a look on ET_C_GENERATOR. Is there any documentation about the translation from AST to C ?

[ebezault]

Unfortunately no. And I must say that the code is not very digestible. Sorry about that.

[ebezault]

As a starter, ET_C_GENERATOR uses the visitor pattern to traverse the AST nodes.
AST nodes represent the "static" version of the code (as it is read from the class text), with classes such as ET_FEATURE, etc.
The generator also uses the "dynamic" version of the code (where each expression is associated with the set of all possible types that it can have at runtime), with classes such as ET_DYNAMIC_FEATURE, etc.

[gchauvet]

Okay, I will start by an implementation of an AST interpreter as first backend for a new project "GEI" (seems more simple than JIT for a first draft).