groovy-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jochen Theodorou <blackd...@gmx.org>
Subject Re: help with an AST
Date Sat, 31 Dec 2016 23:36:07 GMT


On 31.12.2016 17:32, Ed Clark wrote:
[...]
>> Assuming you still want to do something like this with more... AST
>> involvement...
>>
>>> My questions for you are,
>>>
>>>      - is an AST the way to go?
>>
>> first you have to decide what you want to compile to and then we can
>> think about how the AST for that has to look like. So this is actually
>> the last step. But assuming you have some kind of handler object you
>> could compile a+b to handler.invoke("plus",a,b)... in other words you
>> would replace almost any expression by a MethodCallExpression. Hint:
>> ExpressonTransformer and helper classes.
>
> Hmmm, I will have a handler object - sort of - and that's the context
> object itself.  Well, at
> least in the case of instance based contexts.  For class based contexts,
> there won't be
> an instantiated handler, but I could still see having a static "invoke"
> method.
>
> I hadn't considered the invoke approach; it is interesting.  I think it
> would provide some
> additional flexibility that the context developer could use to add
> "operators" beyond the
> ones built into the Groovy parser/AST.  I'll have to think about this
> some more.

the handler object does not have to be the context object itself. It can 
be a collection of context objects, be it classes or instances. It could 
be also be a collection of methods and instances from the context. 
Important for the compiler part is only the calling convention.

>>>      - I'm guessing that I can do the context nesting and composing by building
on
>>>        methodMissing (with ctx2 chaining to ctx3 chaining to Ctx1 above), but
is there
>>>        a better way?
>>
>> I guess the code path for categories won´t help you here, since that
>> is kind of special treated. You could create a special meta class and
>> all the context methods to it, then use its mechanisms to select an
>> appropriate method... hint getMetaMethod, init
>
> Just to be clear, I don't think there is anything special about the
> contexts - they are
> just POGOs.  Their methods just happen to be focused on manipulating
> objects that
> fall under their scope.  So, I'm not sure how creating a meta class
> would help.

you would not really create a meta class of a specific class, you would 
create a meta class in the sense of an enumeration of methods and method 
selection mechanism. But well... now need for that at this point I 
guess. You can of course simply work with methodMissing.

[...]
> Yeah, one of my problems is I think too far ahead ;).  I start worrying
> about what
> it might take to run a marathon when I haven't even learned to walk.  So
> I don't
> even get started.  Part of the this resolution is to just get off my
> butt and write
> some code.

that's a good resolution for the new year ;)

Let me help you: assuming you use "with"-blocks:

Step 1) write an AST transformation that will recognize the with-block 
and store the context in a variable

Step 2) add an expression transformer, that will transform all the 
expressions of interest in the with-block to method calls based on the 
context variable

Step 3) implement a context

Step 4) transform nested with method calls to calls that allow you the 
creation and nesting of a context plus add code to delegate to outer 
contexts

Even if it turns out not to be useful in the end (and I think it will be 
useful) you will still get some practice about writing such things. 
Nothing to really loose here imho ;)

bye Jochen

Mime
View raw message