We are movin AST-interpreter project from dh83 to mate team so you can write on it Guille. 2013/5/16 Marcus Denker <marcus.denker@inria.fr>
On May 14, 2013, at 2:09 PM, Guillermo Polito <guillermopolito@gmail.com> wrote:
Right now, in the image there exist two ways to annotate an AST: - the Opal way - the RB Way
We should simplify that by having only one. So far, the only user of the RB bindings is the ASTInterpreter + the RB tests.
So, I prepared a slice and issue [1], with the following details
- annotate ast using opal annotator - extended OCBindings to read and write from an AST interpreter - not yet made a difference between arg nodes with a different class (just put an if)
I think it might be a good idea to add that⦠what I will do first is to cleanup the OCTemp vars a bit (there is an index variable that is used to sort them at the end, a leftover from back before the closures when there was simple temp=index mapping).
- i didnt add inst vars into the opal bindings for the binding->node relation as in RB, I send the node as a parameter
We need to check this, back pointers are always interesting (but I am not sure if we have a new semantic variable or if we reuse it for multiple nodes?)
- I had to adapt the #compile: into ASTInterpreter because - opal does not annotate other than method nodes Yes, this is because when compiling an expression we transform it do the doIt method before. Expressions can not be compiled standalone.
- undeclared variables raised warnings, not errors
Yes, the idea is that in interactive mode it does user=interaction, while in non-interactive it compiled an Undeclared. (so that the code stays loadable).
Maybe the interpreter could do the same an fall back to Undeclared, that it, undeclared vars are just treated as nil.
Marcus
-- Clément Béra Mate Virtual Machine Engineer Bâtiment B 40, avenue Halley 59650 *Villeneuve d'Ascq*