groovy-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ed Clark <>
Subject Re: help with an AST
Date Sat, 31 Dec 2016 16:32:45 GMT
Hi Jochen,

Thanks for the suggestions.  Replies in line...

On 12/30/2016 03:20 PM, Jochen Theodorou wrote:
> Hi Ed,
> I am wondering if categories would actually do what you want already without touching
the AST. 
> Groovy Categories are actually no syntactic construct and their scope is not lexical
(thread local 
> instead)... but maybe
> Let us assume you have two Strings obj1 and obj2, then you can define a category:
> class StringCategory {
>   static String plus(String obj1, String obj2) { "from StringCategory $obj1 $obj2" }
> }
> and code like this:
> use (StringCategory) {
>   assert "a"+"b" == "from StringCategory a b"
> }
> the construct supports nesting from inside out, that means the inner context wins over
the outer 
> context and the rightmost over the leftmost.
> What this does not support is an instance based context.

I don't think categories will meet my wants.  Categories are a way to enhance a specific class,
whereas I'd like to have my "contexts" deal with objects of a variety of class types.

> 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
> classes.

Hmmm, I will have a handler object - sort of - and that's the context object itself.  Well,
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.

>>      - 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
>>        a better way?
> I guess the code path for categories won´t help you here, since that is kind of special
> You could create a special meta class and all the context methods to it, then use its
> 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.

Remember, I'm trying to get away from the semantics of associating the "plus" in
"obj1 + obj2" back to obj1 (or any potential meta class).  Instead, I'm trying to
associate the "plus" back to the surrounding context (or possibly handler as you
suggest above).

>>      - what might I be breaking in Groovy by doing this?
> that depends on how you do it.
>>      - what help/hints can I get from the compiler vs. doing this all at runtime?
> worry about such things once you have come up with something that works ;)

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.

View raw message