On May 14, 2013, at 2:09 PM, Guillermo Polito <[email protected]> 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
