How do I find the arity of an Expression? (dmd hacking)

[Ellery Newcomer]

On 11/30/2009 07:59 PM, Chad J wrote:
>
> If you care for a bit of reading, I'll tell you my story and ping an idea.
>
> This is about the property expression rewrite of course.  I'd love to
> just use the current convention in dmd and write the rewrite as a
> non-recursive function that gets called at every point in the tree
> whenever someExpr->semantic(sc) is called.  However, there's a snag.
>

Personally, I've come to hate this pattern (just from reading DMD src). 
It seems like the antithesis of code reuse.

> When doing the property rewrite, the inner-most subexpression will need
> to generate the outermost temporaries.
>
> An example:
>
> prop1.prop2 += foo;
>
> AFAIK, the compiler sees this as ((prop1).prop2) += foo; or
> ((prop1()).prop2()) += foo; after resolveProperties is called.  So prop1
> is the innermost expression.
>
> It would be rewritten as this comma expression:
>
> (auto t1 = prop1()),
> (auto t2 = t1.prop2()),
> (t2 += foo),
> (t1.prop2(t2)),
> (prop1(t1))

This is an interesting problem. I like it. Is this rewrite condoned by 
the powers that be? It'd be fun to implement if I ever get this far in 
my semantic analyzer.

>
> So t1 is the outermost temporary, and it corresponds to prop1, the
> innermost expression.
>
> This is problematic in dmd's traditional approach, because the semantic
> pass on prop1 does not have access to it's enclosing expression (as far
> as I can tell).  If it did, I'd just go to the root of the tree, uproot
> the tree, stick it in a comma expression, and just start nesting:

I'm not convinced you need access to the enclosing expression to make 
this rewrite happen. Working it out on paper, it appears to be a matter 
of a few AST copies, keeping track of your t's, and building your comma 
tree (in two directions simultaneously) as you traverse the AST via eg 
semantic.

Here's some chicken scratch that more or less illustrates what I 
envision going on (I can't attest that DMD's ASTs look exactly like 
this, but I assume they're similar):

http://personal.utulsa.edu/~ellery-newcomer/scribble.png

How much effort it would entail is another matter though. I would assume 
you could just add a field or two to struct Expression for pushing 
information up the tree. It seems like copying functionality is already 
there. Pushing 't' information across the tree would probably propagate 
to each special case and be the most annoying part. But basically, every 
time you come across a property, you generate a new symbol and pair of 
pre/post trees. Then at the top, you make a single tree copy with the 
last symbol generated.

>
> Now for the idea.
>
> Currently I'm planning an approach that's a bit more minimalistic than
> the visitor pattern; just to solve my immediate problem.  I will define
> these methods in Expression:
>
> virtual Expression *getChild(unsigned index);
> virtual void setChild(unsigned index, Expression* val);
> virtual unsigned numChildren();
>

I can imagine this would be welcome regardless of how you set about your 
rewrite procedure. I came across a need for something like this as I was 
building my semantic analyzer a while back. Can't wait for school to get 
out so I can get back to work.

> Then I will implement them as needed in the subclasses of Expression.  I
> figure I'd have to write this logic into my function anyways, so I might
> as well make this usable to others.  I've already written a draft of the
> property rewrite that uses these, so I know they get the job done in
> principle.  I just hope this will all be OK in the patch (or even holds
> up under debugging).
>
> So yeah, if I haven't put you to sleep already, please let me know if I
> messed up somewhere.

I do have one nitpick:

auto t1 = p1();

isn't an expression, it's a declaration. That could potentially make 
things difficult for you, particularly when your property assignment is 
deep within an expression tree.

>
> - Chad