Hi all,

I want to summarize this discussion a bit from my perspective.

1.) current Groovy is not fast enough 2.) some want to replace Java with Groovy

So th real problem as I see it is, that people want 1+2, because if you would replace some Groovy code with Java, then it would be fast enough in most cases. But Groovy was not thought as a replacement of Java. It was thought as a friend. I mean... would we have added generic signatures to Groovy if Groovy was thought to replace Java? No, we would not, because Groovy has no benefit from it. Same for Enums for example... we might have done also another form of annotations and there are a lot of other small things that we would have done different. Groovy is designed to work side-by-side with Java.

then there are some things about such a "fast mode" we should shed some light on.... Let me make 3 categories of typing:

1.) dynamic typing:

only the runtime type is used

2.) static typing:

only the compile time type is used, each type must be declared. In some systems the compiler can guess the type well enough to let you omit the type information

3.) mixed typing:

if the static type is not known, the dynamic type will be used.

Groovy has atm dynamic typing. Any change with a fast mode goals a more or less static system, which is a major change for such a language. There is either version 2, which will mean you can not mix dynamic typed parts and static typed parts in the same area and there is version 3 which allows that, but will also give not many hints when it will do static and when it will do dynamic typing.

In my eyes version 3 has many pitfalls, because the way a method call is made will be changed by this. And I do not mean the MOP, I mean the method that will be selected:

def foo (String s) {1} def foo (Object o) {2}

String a = "test" Object b = a def c = a def d = b

// with dynamic typing (version 1) assert foo(a) == 1 assert foo(b) == 1 assert foo(c) == 1 assert foo(d) == 1

// with java style static typing (version 2) // def is like Object assert foo(a) == 1 assert foo(b) == 2 assert foo(c) == 2 assert foo(d) == 2

// with static typing and inference (version 2) // def is infered assert foo(a) == 1 assert foo(b) == 2 assert foo(c) == 1 assert foo(d) == 2

As you can see, the methods that are called differ very much... and I did not even mention our multimethods yet.

Some argue, that they would like to use Groovy, because it has a better syntax... for example with closures. Let us forget a moment about the GDK methods. Let us first look at a usage of Closures:

def foo(closure) { closure() } foo { println 1 }

That is kind of simple. In this version foo does not ensure that "closure" is really a Closure, so "closure()" might fail later... but that can be easily fixed by:

def foo(Closure closure) { closure() } foo { println 1 }

simple and clean for dynamic typing. The essential question for static typing is: How many parameters has my closure and how are they typed? If we look at the Closure class, then we will see that Closure supports any number of arguments. That basically means, that any of these calls is valid and some will fail at runtime:

closure() //ok closure(null) //ok closure(null,null) //fails at runtime closure(null,null,null) //fails at runtime

"{ println 1 }" is a closure that takes 1 or 0 arguments, so the first two calls are ok, the last two are not. And that's not all... the Closure code is in a method doCall implemented, which is not visible in the class Closure.What I want to say, that for Groovy closures, the Closure class contains not enough information to let the compiler produce a direct call and to ensure the call is valid as much as it concerns the types and number of arguments.

That will mean, even if the compiler knows that a closure has two arguments and which types they are and knows that the method will make use of them and that the types are fitting... we can still not make a direct call. And that will mean that a call on a closure will have the speed of a dynamic method call... This can be solved by an annotation, but the code will change:

@ClosureSignature(} def foo(Closure closure) { closure() }

foo { println 1 }

or another example:

@ClosureSignature([Object]} @ClosureSignature([Object,Object]} def foo(Map m, Closure cl) { if (cl.maximumParameters == 2) { m.each {key,value -> cl(key,value)} } else if (cl.maximumParameters == 1) { m.each {entry -> cl (entry)} } } def map = [:] foo (map) {println it} foo (map) {a,b-> println(a); println(b)}

so the validation problem can be solved, but a direct call to the correct method is still impossible this way. If we add a method to Closure which we can call directly, then we would have to add a method that takes any number of arguments, which means that we will need to pack and unpack the arguments in a Object[] for each call... Well, that's probably better than the current situation, but a closure will still be much slower than a direct method call. So looking at the performance only means that you should not use Closure at all then.

Well, we could also define a Set of helper interfaces, which means we will have to throw away optional arguments and which also means, that we now need two methods:

def foo(Map m, <O,O> cl) { m.each {key,value -> cl(key,value)} }

def foo(Map m, <O> cl) { m.each {entry -> cl (entry)} } def map = [:] foo (map) {println it} // closure implements <O> foo (map) {a,b-> println(a); println(b)} // closure implements <O,O>

I guess that is the way the Closure proposals will take.. but it means to either loose optional arguments in whole Groovy, or to double implement/work with redirects. but it is unsure if our solution would conflict with the solution Java might get.

And may I ask what is left of Groovy if we use no closures? Is there enough to have it still as a replacement for Java? Will you still want to replace Java with Groovy in the cases where you need no MOP, no Builder, no Grails and other things?

The way we want to go is to find a fast method selection process, where the selection will be cached at the place where the method call will be done (call site cache) and in later calls we will need only a verification step here, which can be much faster than the normal method selection and which probably can be inlined by the JIT together with the method call itself. This will mean that.

I wrote the things above to show why we talk about a language in a language here. I mean if not even the same methods are called, if many features are no longer available.. That's really another language

bye blackdrag

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

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

http://xircles.codehaus.org/manage_email