replacing GroovyCodeVisitor with something more functional for AST transforms

[HamletDRC]

Hi Gang,

I would like to get your feedback on the complexity/impact of a change
to Groovy I'd like to see.

Currently, we provide a GroovyCodeVisitor that allows you to walk an
AST and make changes to it.

The problem (IMO) with GroovyCodeVisitor is that all the methods
return void. If you want to transform a ReturnStatement into a
MethodCallStatement then you have a lot of work to do within your
"visitReturnStatement(ReturnStatement) : void" method. I'd would be
more functional for my uses if all the visitX() methods returned an
ASTNode object so that you could write a transformation more easily.
In "visitX" you could change the type of X into a Y and have the
parent iteration mechanism assemble the tree correctly. I think
changing the visitor (or providing a 2nd visitor) would make writing
AST Transformations easier.

In my head, it seems like you could write an alternative
visitor/transformer as a library. It shouldn't need any deep hooks or
deep coupling to the current compiler. Do you think that is correct?

A downside of this approach might be the memory usage. It seems this
approach might consume stack frames and blow out the memory pretty
quickly.

Any feedback?

Thanks,

--
Hamlet D'Arcy
hamletdrc@...

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Robert Fischer]

So, if I *don't* want to transform a statement, would I return the statement passed in as the argument?

It'd be pretty easy to use a trampoline instead of recursion to avoid blowing stack/leaking memory,
which would be a pretty severe concern in the design of the app.

~~ Robert Fischer, Smokejumper IT Consulting.
Enfranchised Mind Blog http://EnfranchisedMind.com/blog

Check out my book, "Grails Persistence with GORM and GSQL"!
http://www.smokejumperit.com/gormbook


Hamlet D'Arcy wrote:

> Hi Gang,
>
> I would like to get your feedback on the complexity/impact of a change
> to Groovy I'd like to see.
>
> Currently, we provide a GroovyCodeVisitor that allows you to walk an
> AST and make changes to it.
>
> The problem (IMO) with GroovyCodeVisitor is that all the methods
> return void. If you want to transform a ReturnStatement into a
> MethodCallStatement then you have a lot of work to do within your
> "visitReturnStatement(ReturnStatement) : void" method. I'd would be
> more functional for my uses if all the visitX() methods returned an
> ASTNode object so that you could write a transformation more easily.
> In "visitX" you could change the type of X into a Y and have the
> parent iteration mechanism assemble the tree correctly. I think
> changing the visitor (or providing a 2nd visitor) would make writing
> AST Transformations easier.
>
> In my head, it seems like you could write an alternative
> visitor/transformer as a library. It shouldn't need any deep hooks or
> deep coupling to the current compiler. Do you think that is correct?
>
> A downside of this approach might be the memory usage. It seems this
> approach might consume stack frames and blow out the memory pretty
> quickly.
>
> Any feedback?
>
> Thanks,
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[HamletDRC]

> So, if I *don't* want to transform a statement, would I return the statement
> passed in as the argument?

Exactly.

--
Hamlet D'Arcy
hamletdrc@...


On Sat, Oct 10, 2009 at 12:48 PM, Robert Fischer
<robert.fischer@...> wrote:

> So, if I *don't* want to transform a statement, would I return the statement
> passed in as the argument?
>
> It'd be pretty easy to use a trampoline instead of recursion to avoid
> blowing stack/leaking memory, which would be a pretty severe concern in the
> design of the app.
>
> ~~ Robert Fischer, Smokejumper IT Consulting.
> Enfranchised Mind Blog http://EnfranchisedMind.com/blog
>
> Check out my book, "Grails Persistence with GORM and GSQL"!
> http://www.smokejumperit.com/gormbook
>
>
> Hamlet D'Arcy wrote:
>>
>> Hi Gang,
>>
>> I would like to get your feedback on the complexity/impact of a change
>> to Groovy I'd like to see.
>>
>> Currently, we provide a GroovyCodeVisitor that allows you to walk an
>> AST and make changes to it.
>>
>> The problem (IMO) with GroovyCodeVisitor is that all the methods
>> return void. If you want to transform a ReturnStatement into a
>> MethodCallStatement then you have a lot of work to do within your
>> "visitReturnStatement(ReturnStatement) : void" method. I'd would be
>> more functional for my uses if all the visitX() methods returned an
>> ASTNode object so that you could write a transformation more easily.
>> In "visitX" you could change the type of X into a Y and have the
>> parent iteration mechanism assemble the tree correctly. I think
>> changing the visitor (or providing a 2nd visitor) would make writing
>> AST Transformations easier.
>>
>> In my head, it seems like you could write an alternative
>> visitor/transformer as a library. It shouldn't need any deep hooks or
>> deep coupling to the current compiler. Do you think that is correct?
>>
>> A downside of this approach might be the memory usage. It seems this
>> approach might consume stack frames and blow out the memory pretty
>> quickly.
>>
>> Any feedback?
>>
>> Thanks,
>>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>   http://xircles.codehaus.org/manage_email
>
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Jochen Theodorou]

Hamlet D'Arcy schrieb:

> Hi Gang,
>
> I would like to get your feedback on the complexity/impact of a change
> to Groovy I'd like to see.
>
> Currently, we provide a GroovyCodeVisitor that allows you to walk an
> AST and make changes to it.
>
> The problem (IMO) with GroovyCodeVisitor is that all the methods
> return void. If you want to transform a ReturnStatement into a
> MethodCallStatement then you have a lot of work to do within your
> "visitReturnStatement(ReturnStatement) : void" method. I'd would be
> more functional for my uses if all the visitX() methods returned an
> ASTNode object so that you could write a transformation more easily.
> In "visitX" you could change the type of X into a Y and have the
> parent iteration mechanism assemble the tree correctly. I think
> changing the visitor (or providing a 2nd visitor) would make writing
> AST Transformations easier.

 >
> In my head, it seems like you could write an alternative
> visitor/transformer as a library. It shouldn't need any deep hooks or
> deep coupling to the current compiler. Do you think that is correct?

I suggest you make a small prototype (doesn't have really to work and
doesn't have to cover all) that shows how you want to do things. At last
for me it is more easy to talk about actual code.

bye blackdrag

--
Jochen "blackdrag" Theodorou
The Groovy Project Tech Lead (http://groovy.codehaus.org)
http://blackdragsview.blogspot.com/


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Peter Niederwieser]

If all you need is an easy way to replace AST nodes, have a look at org.codehaus.groovy.transform.powerassert.StatementReplacingVisitorSupport. In Spock, there is also a version for (statements +) expressions.

Cheers,
Peter

HamletDRC wrote:

Hi Gang,

I would like to get your feedback on the complexity/impact of a change
to Groovy I'd like to see.

Currently, we provide a GroovyCodeVisitor that allows you to walk an
AST and make changes to it.

The problem (IMO) with GroovyCodeVisitor is that all the methods
return void. If you want to transform a ReturnStatement into a
MethodCallStatement then you have a lot of work to do within your
"visitReturnStatement(ReturnStatement) : void" method. I'd would be
more functional for my uses if all the visitX() methods returned an
ASTNode object so that you could write a transformation more easily.
In "visitX" you could change the type of X into a Y and have the
parent iteration mechanism assemble the tree correctly. I think
changing the visitor (or providing a 2nd visitor) would make writing
AST Transformations easier.

In my head, it seems like you could write an alternative
visitor/transformer as a library. It shouldn't need any deep hooks or
deep coupling to the current compiler. Do you think that is correct?

A downside of this approach might be the memory usage. It seems this
approach might consume stack frames and blow out the memory pretty
quickly.

Any feedback?

Thanks,

--
Hamlet D'Arcy
[e-mail]

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email




-----
--
Hamlet D'Arcy