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