• Chad J (21/21) Sep 24 2009 I'm spending some of my spare time implementing expression rewriting for
• Chad J (2/6) Sep 24 2009 I forgot to clarify. I meant read property /calls/.
• Ary Borenszweig (2/28) Sep 24 2009 Is CommaExp what you are looking for?
• Chad J (6/8) Sep 24 2009 That seems to be exactly what I'm looking for.

Chad J <chadjoan __spam.is.bad__gmail.com> writes:

I'm spending some of my spare time implementing expression rewriting for
properties.

One thing I've noticed that bugs me is how resolveProperties is
scattered all over the place in statement.c and expression.c.  I'm
wondering why it's called so zealously.

It bugs me because I'm worried that read properties can be generated by
some of the semantic analysis code after I've already done my rewrites.
 I want to do my rewrite before properties are resolved, and at the same
time this must be done in CompoundStatement::semantic(...) since I need
the parent compound statement of any expression being rewritten.

If there was some kind of block expression type (CompoundExpression?)
that defined ordered execution of expressions within another expression,
then I wouldn't need parent CompoundStatements at all.  I haven't
noticed such a beast in the sources though, and I suspect that
implementing one would involve some backend hacks that I don't want to risk.

For now I'll move ahead on the assumption that read properties aren't
going to pop out of nowhere after I've done my thing, but I would like
to know if I'm going about this wrong or just inherited some significant
refactoring work.

Thanks,
- Chad

Chad J <chadjoan __spam.is.bad__gmail.com> writes:

Chad J wrote:
 
 It bugs me because I'm worried that read properties can be generated by
 ...
 

I forgot to clarify.  I meant read property /calls/.

Ary Borenszweig <ary esperanto.org.ar> writes:

Chad J wrote:
 I'm spending some of my spare time implementing expression rewriting for
 properties.
 
 One thing I've noticed that bugs me is how resolveProperties is
 scattered all over the place in statement.c and expression.c.  I'm
 wondering why it's called so zealously.
 
 It bugs me because I'm worried that read properties can be generated by
 some of the semantic analysis code after I've already done my rewrites.
  I want to do my rewrite before properties are resolved, and at the same
 time this must be done in CompoundStatement::semantic(...) since I need
 the parent compound statement of any expression being rewritten.
 
 If there was some kind of block expression type (CompoundExpression?)
 that defined ordered execution of expressions within another expression,
 then I wouldn't need parent CompoundStatements at all.  I haven't
 noticed such a beast in the sources though, and I suspect that
 implementing one would involve some backend hacks that I don't want to risk.
 
 For now I'll move ahead on the assumption that read properties aren't
 going to pop out of nowhere after I've done my thing, but I would like
 to know if I'm going about this wrong or just inherited some significant
 refactoring work.
 
 Thanks,
 - Chad

Is CommaExp what you are looking for?

Chad J <chadjoan __spam.is.bad__gmail.com> writes:

Ary Borenszweig wrote:
 
 Is CommaExp what you are looking for?

That seems to be exactly what I'm looking for.

I did not know CommaExp did that.

This is most excellent.  Now I can just integrate my code into
resolveProperties and be fairly certain that everything will work out.

Thank you!