[Compiler-sig] Assign nodes

[Jeremy Hylton]

>>>>> "FB" == Finn Bock <bckfnn@worldonline.dk> writes:

  FB> And I don't like this change one single bit. Yes sure, it looks
  FB> prettier than using Lvalue and it captures useful information,
  FB> but it makes a one-pass AST builder a lot harder to do.

I felt it simplified the code generator for the compiler package, but
I don't have any experience with a one-pass AST builder.  So it's hard
for me to judge what the tradeoffs are.  You haven't written a code
generator, right?  If so, we've each got experience with one end of
the problem, but not with both.

  FB> You probably don't care because you have an intermediate parse
  FB> tree with all the context needed to know if you must create a
  FB> Name node or a AssignName node.

I'd be interested in taking a look at the one-pass AST builder.
Eventually, I'd like to have one for CPython.  

  FB> When my parser detect a name, I have no way of knowing if an
  FB> equal sign will turn up later. So I'll have to pick one node
  FB> type (like Name) and rebuild that part of the tree later if it
  FB> turned out that it was part of an assignment or deletion. Ugly.

Indeed, and perhaps a compelling case against the richer AST.  I
assume the difference is that CPython's compiler is top-down and yours
is bottom-up?

  FB> As I have said before, I think the desire for correct typing in
  FB> the tree is overrated and I would rather remove the 'assign' sum
  FB> altogether and add a flag to the Attribute, Subscript, Name,
  FB> List and Tuple nodes that captured the use of the node (like
  FB> 'Get', 'Set' and 'Del').

I'll noodle with the code generator in the compiler package and see
what it would look like if the AssignXXX nodes went away.

Jeremy