Re: AST transformations

[jvb@uwyo.edu]

Etienne. Here are some of my current thoughts on the AST transformer.
Please let me know what you think. I may or may not proceed with this
depending on what you have to say.

The basic idea is to be able to write equalities between subtrees of
an AST.  These equalities will be treated as rewrite rules (left to
right) and would be compiled into JAVA code.

As an example, here is the rough idea for rules that would deal
with your example of transforming a mult_assign into a list of
single_assigns.

rule [nicer_assign]
mult_assign(id*(id(?X),$Rest),assign,num*(num(?N),$Rest2)) 
   =
single_assign(id(?X),assign,num(?N)),mult_assign($Rest1,assign,$Rest2)

rule [nicer_assign_end]
mult_assign(id*(),assign,num*()) = empty

The idea of the first rule is that the lhs of the rule matches a
subtree whose root is a mult_assign node containing a nonempty list of
ids, an assign, and a nonempty list of nums.  Two types of pattern
matching variables occur in the rule. ?vars match any single node in
the tree and $vars match lists of nodes in the tree. $vars can only
occur in a list context, i.e., inside seomthing like id* as above.

When the lhs pattern matches a subtree in an AST, that subtree is
replaced by the subtree described in the rhs, with variables
instantiated with what was matched on the lhs. (Variables may not
appear only on the rhs but can appear only on the lhs.)

One problem with the rule above is that it replaces an mult_assign
node with two nodes, a single_assign and a new mult_assign. One
solution would be to modify the grammar, to allow a block of
statements to appear where ever a statement can.

The second rule removes empty mult_assign statements. 

The idea goes further allowing rule sets to be applied to ASTs via
different control strategies using different types of Adaptors
(similar to what you talked about in your thesis).

I'm sure that there are errors in the syntax of the rules I wrote
above, but this is the idea.

Jeff
----