gmane.comp.lang.groovy.devel

Re: [groovy-dev] Adding < at >Trait to Groovy

Jochen Theodorou — 2013-06-20T02:38:57

Am 19.06.2013 16:54, schrieb Matthew Adams:
[...]

As long as < at >Trait is not supposed to be a static-compilation-only thing 
(and with that no replacement for < at >Mixin), it is something we have to 
deal with.


we compile the class the trait is changing. Manipulating he target of 
the trait is not the problem - the trait itself is.

bye blackdrag

Re: [groovy-dev] Adding < at >Trait to Groovy

Remi Forax — 2013-06-19T22:05:26

You don't need to duplicate the AST. You need a way to reference the 
code generated from the AST.
This is how Java 8 works, when you have an interface with a default 
method and a class that implements this interface,
the class override the method of the interface and generate a call that 
just call the method of the interface.

By example with,
interface I {
   default void foo() { ... }
}
class A implements I { }

the VM change the code of A at linking time (it can be done at loading 
time if you don't control the VM
or at compile time if you don't control the classloader) to

class A implements I {
   public void foo() {
      I.super.foo();    // this ugly syntax if an invokespecial in fact
   }
}

You can do the same things in Groovy but because you don't control the 
VM you need to generate
two classes for one trait, the interface with no code and the companion 
class (also named garbage class)
that contains the code in a static method.

So in Groovy,
   < at >Trait
   class I {
     def foo() { ... }
}
c

Re: [groovy-dev] Adding < at >Trait to Groovy

Guillaume Laforge — 2013-06-19T18:23:32

That's the idea: provide a better replacement for < at >Mixin,  and deprecate
< at >Mixin.

Guillaume
Le 19 juin 2013 18:06, "Graeme Rocher" <graeme.rocher-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org> a écrit :

Re: [groovy-dev] Adding < at >Trait to Groovy

Cédric Champeau — 2013-06-19T17:33:40

Right, so the discussion moves to delegate approach vs bytecode "copy". 
The first one is obviously easier to implement, while the second one can 
have problems with conflicting members (same name for fields, for example).

There are two cases to consider:
     1. the trait is precompiled
     2. the trait is compiled at the same time as we use it

In the first case, bytecode is available so we could leverage ASM4 to 
migrate bytecode from the trait to the generated class. This can be done 
in a late compilation phase (during class generation), but for the 
methods to be available, we need them to be visible in an earlier phase, 
but I think classical reflection should be enough here (stubbed method 
bodies). In the second case (not precompiled), we would need to 
duplicate the AST tree from the trait into the target class, which is 
more complex than it seems (we don't have anything that can be cloned).

I'll try to experiment around this.

Le 19/06/2013 16:54, Matthew Adams a écrit :

Re: [groovy-dev] Adding < at >Trait to Groovy

Johannes Link — 2013-06-19T16:18:58

Graeme,

Maybe you can elaborate a bit on why < at >Mixin does not work the way it should
and why it can't be fixed?

cheers, Johannes

2013/6/19 Graeme Rocher <graeme.rocher-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org>

Re: [groovy-dev] Adding < at >Trait to Groovy

Graeme Rocher — 2013-06-19T16:04:53

On that note, if this is implemented please, please deprecate < at >Mixin at the
same time


On Tue, Jun 18, 2013 at 8:14 PM, Jochen Theodorou <blackdrag-BA+cFGlbTmA< at >public.gmane.org> wrote:

Re: [groovy-dev] Adding < at >Trait to Groovy

Matthew Adams — 2013-06-19T14:54:12

Clement & crew, though.

definitely not as familiar with the dynamic environment as you guys are,
and I appreciate that there are things that are not available in that
environment.

Having said that, it seems to me, conceptually, that if Groovy could at
runtime add fields & methods to classes, which I'd imagine would require
the unloading, manipulation, and reloading of the class via some magical
ClassLoader, then I think you'd have a solution.  WDYT?  Is that even
possible, let alone crazy?

For the statically typed areas of Groovy, it seems like you could piggy
back on the work of AspectJ for field & method introduction.  Mind you, I
think the AspectJ guys would like to formalize the notion of traits
themselves, since they're so close to having them natively; Andy expressed
as much at
http://aspectj.2085585.n4.nabble.com/Trait-syntax-sugar-tp4650566p4650569.html.
 Thoughts?

Fruitful & fun discussion!  :)

-matthew

Re: [groovy-dev] Adding < at >Trait to Groovy

Jochen Theodorou — 2013-06-19T07:51:03

Am 18.06.2013 22:34, schrieb Matthew Adams:
[...]

yes, but if the state is in the class the trait is used on and not in 
the trait implementation, then how to access that state while still 
being able to access multiple cases of this trait being used on? It is 
not like you can declare the fields in an interface and then use the 
interface to access them. What I could imagine atm is to have helper 
methods for that, which would have to become part of the interface. 
While possible, that is surely no nice solution.


There is one point that is probably a bit difficult to see.

Normally in Java (and Scala or AspectJ) you work at compile time in a 
static bound compilation environment. Meaning you have source and/or 
bytecode available. And that not only for the results of your compiler, 
but also for what the compiler uses to produce these results. This 
allows you for example to read information that is only available if you 
read the bytecode from a file... like annotations without runtime 
visibility.

In

Re: [groovy-dev] Sanity check on Trampoline

Jochen Theodorou — 2013-06-19T07:34:59

Am 19.06.2013 08:43, schrieb Johannes Link:
[...]

What do you think has still to be done?

bye blackdrag

Re: [groovy-dev] Sanity check on Trampoline

Jochen Theodorou — 2013-06-19T07:34:06

Am 15.06.2013 13:40, schrieb Russel Winder:

We have to realize why it is slow. On the JVM a normal method call is 
very fast (even compared to virtual method calls in for example C++). 
Anything you do here additionally, and even if it is the smallest thing, 
will have a speed impact. Especially bad is it here to have any volatile 
or other synchronization elements in play. And that is why trampoline 
cannot be fast, the value is stored in a thread aware map... So unless 
you can use it to quite long running calls, it is simply not the right 
thing to do.

A while loop inside the method body with a constant condition so that 
the loop is actually only some jump instructions is much better here. 
That is what Scala does.

My continuation style tail recursion optimization you mention could be 
much faster than it is today, especially in the self recursive case. It 
can "solve" general tail recursion though, not only the self recursive 
ones and is fully dynamic. Still, even in the best case it is probably 
no

Re: [groovy-dev] Sanity check on Trampoline

Jochen Theodorou — 2013-06-19T07:15:49

Am 17.06.2013 11:33, schrieb Dinko Srkoč:
[...]

There should be different versions of that in the net, but basically it 
is in the style of what I described here: 
http://blackdragsview.blogspot.de/2006/08/tail-recursion-in-groovy.html

bye blackdrag

Re: [groovy-dev] Sanity check on Trampoline

Cédric Champeau — 2013-06-19T06:54:59

What I mean is not that we should limit TCO to < at >CompileStatic. I'm just 
saying that if you apply TCO on code which is *not* < at >CompileStatic, you 
*might* change semantics. In practice, this would be very rare, but it's 
worth mentionning :)

As for contributing, I would suggest you create a branch from master, 
put your implementation and tests here then create a pull request, so 
that others may comment, test and improve.

Le 19/06/2013 08:43, Johannes Link a écrit :

Re: [groovy-dev] Sanity check on Trampoline

Johannes Link — 2013-06-19T06:43:15

2013/6/18 Cédric Champeau <cedric.champeau-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org>


I'm not sure I fully agree. Just standard (and static) Java polymorphism
could break TCO semantics, I assume. By annotating a method < at >TailRecursive
a developer confirms that TCO will work here, it's a decision to take
responsibly. By restricting it to statically compiled code we might make
TCO somewhat less useful without real security.



If I can be of any help in achieving that, just let me know.

Johannes

Re: [groovy-dev] Adding < at >Trait to Groovy

Matthew Adams — 2013-06-18T20:34:12

JDK 8 interface with its default methods, but plus fields.

I don't currently see traits as being established at runtime; they are a
compile-time introduction, IMHO.  You use bytecode manipulation to
introduce the fields, methods, and 'implements' declaration into the
expressing class.

The pattern is supported and well-established in AspectJ (I know Groovy is
not AspectJ), but I feel the same compile-time processes would be at work
introducing the trait into the expressing classes -- see
http://aspectj.2085585.n4.nabble.com/Trait-syntax-sugar-tt4650566.html#a4650981
.

In the end, that there is only the 'this' reference, and it is
indistinguishable both in the trait's methods and in the expressing class.
 If you do it via delegation, you will render Groovy traits less useful
than they would be with introduction. IMHO.

-matthew

Re: [groovy-dev] Sanity check on Trampoline

Russel Winder — 2013-06-18T19:25:53

Hummm… Does TCO really require static compile? I guess we have to
exchange a few examples and try it out. I appreciate your concerns about
dynamic rebinding but I am not sure if it is a "blocker" in dynamic
semantics.

On the other hand if < at >TailRecursion has to enforce < at >CompileStatic I
think I am entirely happy.


Oh all right :-)

As I only actually use 2.2.0-SNAPSHOT just now I am not really concerned
with ancient history like 2.1.5 and earlier ;-)

Re: [groovy-dev] Sanity check on Trampoline

Cédric Champeau — 2013-06-18T19:10:54

Yes, we are interested in TCO, very interested I would say, but never 
got time to implement it. As a side note, this only makes "real" sense 
if statically compiled, otherwise you must be aware that the 
optimization *may* change the semantics of the original code (as there's 
in general no reason why the recursive call would call the same method 
afterwards, we're in a dynamic world...).

Now, if it goes into Groovy, that would be for a 2.2/2.3 release, not a 
2.1.x (bugfix releases).

Le 18/06/2013 21:04, Russel Winder a écrit :

Re: [groovy-dev] Sanity check on Trampoline

Russel Winder — 2013-06-18T19:04:34

I had missed this. I think we should make this production quality and
part of the Groovy distribution in 2.1.6 and 2.2.0-SNAPSHOT asap.

Re: [groovy-dev] Adding < at >Trait to Groovy

Jochen Theodorou — 2013-06-18T18:14:01

Am 18.06.2013 19:34, schrieb Dierk König:

This is not so much about adding a new feature, but more about replacing 
the error prone < at >Mixin

bye blackdrag

Re: [groovy-dev] Adding < at >Trait to Groovy

Jochen Theodorou — 2013-06-18T17:57:35

Am 18.06.2013 17:25, schrieb Matthew Adams:

only that I don't know how to implement that. What I am thinking of here 
is the case that the trait is something precompiled or runtime compiled. 
Just copying over is difficult if you cannot be sure to have access to 
source and/or bytecode.

That's why I currently do not see how to implement that without delegation.

bye blackdrag

Re: [groovy-dev] Adding < at >Trait to Groovy

Dierk König — 2013-06-18T17:34:17

I just want to make sure that all involved parties know about all the meta prog features that we already have. Regina chap 8 and 9 are a good read on that. 
I doubt that we need more and we should avoid feature envy and following paths that may make sense in other langs but not necessarily in Groovy where we integrate with current and future Java. 
Cheers
Dierk

sent from:mobile 

Am 18.06.2013 um 17:25 schrieb Matthew Adams <matthew-i0dBfVS/lx4ODPX2qTFnTw< at >public.gmane.org>:

Re: [groovy-dev] Adding < at >Trait to Groovy

Matthew Adams — 2013-06-18T15:25:56

that.  In fact, what I'm suggesting is that 'this is that' would return
true.  In your example, what is the type of 'that'?  Of 'this'?  What I'm
getting at is that a trait's fields & methods are *introduced* into the
expressing class.  Inside the trait's methods, there is no distinction
between the trait instance and the expressing class instance; they are one
and the same and of the trait's type.  There *is* no that; it's this.

Your suggestion, and correct me if I'm wrong, asserts '!(this is that)',
which sounds more like delegation is underpinning the design, which is what
I'm against for the aforementioned persistence reasons.





-matthew