[Compiler-sig] changes to ast

[John Ehresman]

On Wed, 1 Nov 2000, Jeremy Hylton wrote:
> What kind of tree does the Wing IDE code produce?  I saw the
> announcement, but haven't had time to look at it.

The tree produced by the nodetransformer module in the parsetools package
is similiar, but not identical to the tree produced by the transformer
module.  It can either be generated as a series of nested tuples, where
the 1st item is the name of the node's class, or it can be generated as a
series of class instances if the ast module is available.  There are also
a number of other, more substantial, differences, such as how assignments
are encoded; rather than multiple varients of assigns for tuples, attribs,
& so forth, there is a single assign class with right-hand-side &
left-hand-side children.  At one point, I was going to propose changes to
the ast, but now I wonder if it would be simpler to mimic the Python
transformer exactly -- because it's easier for me to document and justify
the behavior ;).

If I recall correctly, the 2 main hotspots in the python transformer were
converting the parser tree to a tuple and transforming a test parse node
in the common case where it's a simple atom.  You might get a noticable
improvement with a loop in the test node transform to call directly to the
atom transform if all in between nodes have only one child.  Converting
the parse tree is harder to optimize; I did create a new node wrapper
class which only converts to Python data types as needed, but if all
tranformation is done in Python, the entire tree will need to be converted
anyway.

BTW: The Wing IDE does use this transformer internally, but there's no way
to get at the parse tree directly with the IDE.  The transformer and
supporting modules are packaged up as the parsetools package at
ftp://archaeopteryx.com/pub/parsetools/.

John