Mailing-List: contact users-help@groovy.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@groovy.apache.org
Subject: Re: help with an AST
To: users@groovy.apache.org
References: <ef9e9540-74b4-5e79-e225-cfbfde46ac42@ameritech.net>
 <5866C1A8.6020809@gmx.org>
From: Ed Clark <eaclark@ameritech.net>
Message-ID: <337fe01e-3af4-5345-cd5f-8836cd565a94@ameritech.net>
Date: Sat, 31 Dec 2016 11:32:45 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
 Thunderbird/45.4.0
MIME-Version: 1.0
In-Reply-To: <5866C1A8.6020809@gmx.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
archived-at: Sat, 31 Dec 2016 16:32:57 -0000

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


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

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.