Jython

On Mon, Jun 18, 2012 at 1:03 AM, Jez <jezreel@...> wrote:
> Hi,
>
> I was trying to fix #1910 and related issues by checking that the targets in
> 'for [target] in ...' and 'except Exception as [target]' are assignable
> expressions. However, rather than adding checkAssign calls at those sites, I
> wonder if it would be more elegant to do a check whenever we construct an
> expression. Specifically, I was thinking of calling checkGenericAssign() in
> the @after hooks of both 'expr' and 'test' constructors whenever the
> contextType is 'Store'. This approach should also eliminate the need for the
> checkAssign call, since every component of a Tuple or List that is used in a
> 'Store' context should have been verified to be assignable already.
That sounds like a good idea, thanks for looking into it!

> Are there any problems with this approach, or does it sound good?
I can't think of any off the top of my head - it would be nice to
eliminate the recursion on that one.

> Also, I'm not clear what the difference between the expr.etype and expr.tree
> attributes are. Would be great if someone enlightened me :)
etype is our own return type. ANTLR produces expr.tree automatically,
but in a form that we can't use directly. IIRC the only time I need to
use expr.tree is when we need to collect nodes with +=

I'll double check to make sure I'm correct about expr.tree, it's been a while.

-Frank

On Mon, Jun 18, 2012 at 9:46 AM, fwierzbicki@...
<fwierzbicki@...> wrote:
>> Also, I'm not clear what the difference between the expr.etype and expr.tree
>> attributes are. Would be great if someone enlightened me :)
> etype is our own return type. ANTLR produces expr.tree automatically,
> but in a form that we can't use directly. IIRC the only time I need to
> use expr.tree is when we need to collect nodes with +=
OK ignore this explanation - I should have looked at the grammar
first. I'll give a better explanation after I've had a look.

-Frank

So trying again on tree vs etype in Jython's use of ANTLR:

So anywhere that you see "foo.tree" -- tree is a node generated by
ANTLR and is of type PythonTree due to this declaration at the top of
Python.g:

options {
     ASTLabelType=PythonTree;
     output=AST;
}

The places where you see things like expr.etype is where I have named
a variable to pass it back up to other rules, so for example the
yield_expr rule looks like this:

//yield_expr: 'yield' [testlist]
yield_expr
    returns [expr etype]
@after {
    //needed for y2+=yield_expr
    $yield_expr.tree = $etype;
}
    : YIELD testlist[expr_contextType.Load]?
      {
          $etype = new Yield($YIELD, actions.castExpr($testlist.tree));
      }
    ;

the expression

   returns [expr etype]

Says that I have a return variable named etype that is of type expr.

The line

          $etype = new Yield($YIELD, actions.castExpr($testlist.tree));

creates a new Yield node and assigns it to the return variable named
etype. On the same line "$testlist.tree" grabs the tree node from the
testlist rule that must be visited to complete yield_expr.

testlist assigns an expr to its "tree" -- here is where I get a little
fuzzy -- it seems like I should have just given testlist a return
variable like I do in other places, but for some reason that doesn't
work in a number of places in the grammar. Instead I go through a
little dance and assign the expr to the tree in an @after clause.

If I remember why I do this I'll add a note here. Once I get my head
straight on the above maybe I can work it into a more coherent doc or
weblog post.

-Frank

I should really do more editing before hitting send -- at the top of
the last post I said

So anywhere that you see "foo.tree" -- tree is a node generated by
ANTLR and is of type PythonTree

But by the end I was saying that I replaced these with my own
PythonTree (so the "anywhere that you see" doesn't really hold up)

The reason I am doing this instead of just passing named return vales
like etype is that grammar code like this:

     -> or_test

Just passes the .tree part up to the next rule without providing
access to the named return variables, so I have to put the etype into
the "tree" area so I can get to it in upstream rules. It would be
better if these usages where more consistant.

-Frank