Quantcast

static compilation for Groovy

classic Classic list List threaded Threaded
52 messages Options
1234 ... 6
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

static compilation for Groovy

Dierk König
Hiall,

given the latest discussions, I'd like to voice an opinion here
regarding the static compilation ideas.

Groovy dispatches by runtime type.

def foo(String x) { println 'String'}
def foo(Object x) { println 'Object'}

Object x = "Groovy"
foo x

prints "String" in Groovy (dispatch by runtime type)
but "Object" in Java (dispatch by static type).

Changing this would be a major language change.
Pretty much all relevant Groovy codebases that I know
of would be affected.

And what would we gain?
1) Performance
2) Static type checking

But both is already catered for by other means
up to an extend that makes sense for Groovy.

My considered opinion is that any static compilation
could only take place in extremely restricted areas where
1) the runtime-time type can be proven to always be the compile-time type
2) we do not want the MOP to be in charge of the dispatch.

IMHO this doesn't leave much area of applicability.

cheers
Dierk


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

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: static compilation for Groovy

Cédric Champeau

Le 10/11/2011 19:51, Dierk König a écrit :
> Hiall,
hi!
> given the latest discussions, I'd like to voice an opinion here
> regarding the static compilation ideas.
good!

> Groovy dispatches by runtime type.
>
> def foo(String x) { println 'String'}
> def foo(Object x) { println 'Object'}
>
> Object x = "Groovy"
> foo x
>
> prints "String" in Groovy (dispatch by runtime type)
> but "Object" in Java (dispatch by static type).
Well, this discussion is closely tied to another problem, which is
supporting multimethods in static mode too. The idea here is to keep
semantics close to what Groovy does. It should already work in cases
where we can infer the type at compile time, like in your example (with
the idea that dispatch is based on inferred type). Having a complete
implementation of multimethods which supports the whole semantics of the
current groovy dispatch would somehow be more complicated (could mean
generate a method with multiple instanceof checks, but this would kill
performance), but certainly doable. We could process in various phases
until a possible release, with experiments on what we're able to do.
Furthermore, the support of invokedynamic could also help a lot in that
direction.

> Changing this would be a major language change.
> Pretty much all relevant Groovy codebases that I know
> of would be affected.
>
> And what would we gain?
> 1) Performance
> 2) Static type checking
>
> But both is already catered for by other means
> up to an extend that makes sense for Groovy.
>
> My considered opinion is that any static compilation
> could only take place in extremely restricted areas where
> 1) the runtime-time type can be proven to always be the compile-time type
> 2) we do not want the MOP to be in charge of the dispatch.
>
> IMHO this doesn't leave much area of applicability.
>
> cheers
> Dierk
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>      http://xircles.codehaus.org/manage_email
>
>
>


--
Cédric Champeau
SpringSource - A Division Of VMware
http://www.springsource.com/
http://twitter.com/CedricChampeau


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

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: static compilation for Groovy

Jochen Theodorou
In reply to this post by Dierk König
Am 10.11.2011 19:51, schrieb Dierk König:
[...]
> My considered opinion is that any static compilation
> could only take place in extremely restricted areas where
> 1) the runtime-time type can be proven to always be the compile-time type
> 2) we do not want the MOP to be in charge of the dispatch.
>
> IMHO this doesn't leave much area of applicability.

I see here more a question of the user group. On Java7 for example it is
still open, how much you lose using invokedynamic compared to direct
method calls. Static types can help invokedynamic, and I wonder if the
future for static compilation of groovy lies not in invokedynamic, and
with that, actually not really doing static compilation.

The problems are what we give people that are not on Java7 the next 4
years and that current Groovy's MOP has some things preventing
invokedynamic to use full power.

The question is then actually... should we give people something for pre
Java7 or not? ... well, assuming invokedynamic (maybe with static type
checks) is about as fast as Java style compiled Groovy would be.

bye blackdrag


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

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: static compilation for Groovy

Russel Winder
My fear here is that the direction of Groovy panders to the static type
adherents who despise all dynamic languages, and are very vocal in
damning Groovy because it is not Java, Scala, Kotlin, Ceylon.

I don't want Groovy to be a failed Java 8 wannabee.  I want a dynamic
language to use as a complement to Java.  For performance critical
sections of code I use Java.  For dynamic components I use Groovy.  This
element of purity leads to clean and clear models of use.  This is an
easy sell in the training, take up and leveraging games.

Turning Groovy into a mish-mash language trying to kowtow to the wants
of a disparate and conflicting set of requirements seems like a recipe
for the demise of the language.

Groovy should not and should not even try to be a better Java.  It is a
symbiotic partner bringing different capabilities.  This is Groovy's
USP, and its sole reason for existing.

--
Russel.
=============================================================================
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:[hidden email]
41 Buckmaster Road    m: +44 7770 465 077   xmpp: [hidden email]
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: static compilation for Groovy

Dierk König
+1

Am 11.11.2011 um 10:59 schrieb Russel Winder:

> My fear here is that the direction of Groovy panders to the static type
> adherents who despise all dynamic languages, and are very vocal in
> damning Groovy because it is not Java, Scala, Kotlin, Ceylon.
>
> I don't want Groovy to be a failed Java 8 wannabee.  I want a dynamic
> language to use as a complement to Java.  For performance critical
> sections of code I use Java.  For dynamic components I use Groovy.  This
> element of purity leads to clean and clear models of use.  This is an
> easy sell in the training, take up and leveraging games.
>
> Turning Groovy into a mish-mash language trying to kowtow to the wants
> of a disparate and conflicting set of requirements seems like a recipe
> for the demise of the language.
>
> Groovy should not and should not even try to be a better Java.  It is a
> symbiotic partner bringing different capabilities.  This is Groovy's
> USP, and its sole reason for existing.
>
> --
> Russel.
> =============================================================================
> Dr Russel Winder      t: +44 20 7585 2200   voip: sip:[hidden email]
> 41 Buckmaster Road    m: +44 7770 465 077   xmpp: [hidden email]
> London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder


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

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: static compilation for Groovy

tim yates-2
In reply to this post by Russel Winder
+1

On 11 November 2011 09:59, Russel Winder <[hidden email]> wrote:
My fear here is that the direction of Groovy panders to the static type
adherents who despise all dynamic languages, and are very vocal in
damning Groovy because it is not Java, Scala, Kotlin, Ceylon.

I don't want Groovy to be a failed Java 8 wannabee.  I want a dynamic
language to use as a complement to Java.  For performance critical
sections of code I use Java.  For dynamic components I use Groovy.  This
element of purity leads to clean and clear models of use.  This is an
easy sell in the training, take up and leveraging games.

Turning Groovy into a mish-mash language trying to kowtow to the wants
of a disparate and conflicting set of requirements seems like a recipe
for the demise of the language.

Groovy should not and should not even try to be a better Java.  It is a
symbiotic partner bringing different capabilities.  This is Groovy's
USP, and its sole reason for existing.

--
Russel.
=============================================================================
Dr Russel Winder      t: <a href="tel:%2B44%2020%207585%202200" value="+442075852200">+44 20 7585 2200   voip: [hidden email]
41 Buckmaster Road    m: <a href="tel:%2B44%207770%20465%20077" value="+447770465077">+44 7770 465 077   xmpp: [hidden email]
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: static compilation for Groovy

Chanwit Kaewkasi
In reply to this post by Russel Winder
+1


On 11/11/2011, Russel Winder <[hidden email]> wrote:

> My fear here is that the direction of Groovy panders to the static type
> adherents who despise all dynamic languages, and are very vocal in
> damning Groovy because it is not Java, Scala, Kotlin, Ceylon.
>
> I don't want Groovy to be a failed Java 8 wannabee.  I want a dynamic
> language to use as a complement to Java.  For performance critical
> sections of code I use Java.  For dynamic components I use Groovy.  This
> element of purity leads to clean and clear models of use.  This is an
> easy sell in the training, take up and leveraging games.
>
> Turning Groovy into a mish-mash language trying to kowtow to the wants
> of a disparate and conflicting set of requirements seems like a recipe
> for the demise of the language.
>
> Groovy should not and should not even try to be a better Java.  It is a
> symbiotic partner bringing different capabilities.  This is Groovy's
> USP, and its sole reason for existing.
>
> --
> Russel.
> =============================================================================
> Dr Russel Winder      t: +44 20 7585 2200   voip:
> sip:[hidden email]
> 41 Buckmaster Road    m: +44 7770 465 077   xmpp: [hidden email]
> London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
>

--
Sent from my mobile device

Chanwit Kaewkasi
code.google.com/p/zkgrails
twitter.com/chanwit

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

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: static compilation for Groovy

ld@ldaley.com
In reply to this post by Russel Winder

On 11/11/2011, at 9:59 AM, Russel Winder wrote:

> My fear here is that the direction of Groovy panders to the static type
> adherents who despise all dynamic languages, and are very vocal in
> damning Groovy because it is not Java, Scala, Kotlin, Ceylon.
>
> I don't want Groovy to be a failed Java 8 wannabee.  I want a dynamic
> language to use as a complement to Java.  For performance critical
> sections of code I use Java.  For dynamic components I use Groovy.  This
> element of purity leads to clean and clear models of use.  This is an
> easy sell in the training, take up and leveraging games.
>
> Turning Groovy into a mish-mash language trying to kowtow to the wants
> of a disparate and conflicting set of requirements seems like a recipe
> for the demise of the language.
>
> Groovy should not and should not even try to be a better Java.  It is a
> symbiotic partner bringing different capabilities.  This is Groovy's
> USP, and its sole reason for existing.

Well said, I agree completely.

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

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: static compilation for Groovy

Václav Pech
In reply to this post by Russel Winder
Close to what I feel (and fear).

On Fri, Nov 11, 2011 at 10:59 AM, Russel Winder <[hidden email]> wrote:
My fear here is that the direction of Groovy panders to the static type
adherents who despise all dynamic languages, and are very vocal in
damning Groovy because it is not Java, Scala, Kotlin, Ceylon.

I don't want Groovy to be a failed Java 8 wannabee.  I want a dynamic
language to use as a complement to Java.  For performance critical
sections of code I use Java.  For dynamic components I use Groovy.  This
element of purity leads to clean and clear models of use.  This is an
easy sell in the training, take up and leveraging games.

Turning Groovy into a mish-mash language trying to kowtow to the wants
of a disparate and conflicting set of requirements seems like a recipe
for the demise of the language.

Groovy should not and should not even try to be a better Java.  It is a
symbiotic partner bringing different capabilities.  This is Groovy's
USP, and its sole reason for existing.

--
Russel.
=============================================================================
Dr Russel Winder      t: <a href="tel:%2B44%2020%207585%202200" value="+442075852200">+44 20 7585 2200   voip: [hidden email]
41 Buckmaster Road    m: <a href="tel:%2B44%207770%20465%20077" value="+447770465077">+44 7770 465 077   xmpp: [hidden email]
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder



--
E-mail: [hidden email]
Blog: http://www.jroller.com/vaclav
Linkedin page: http://www.linkedin.com/in/vaclavpech
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: static compilation for Groovy

Graeme Rocher-4
In reply to this post by ld@ldaley.com
On Fri, Nov 11, 2011 at 11:52 AM, [hidden email] <[hidden email]> wrote:

>
> On 11/11/2011, at 9:59 AM, Russel Winder wrote:
>
>> My fear here is that the direction of Groovy panders to the static type
>> adherents who despise all dynamic languages, and are very vocal in
>> damning Groovy because it is not Java, Scala, Kotlin, Ceylon.
>>
>> I don't want Groovy to be a failed Java 8 wannabee.  I want a dynamic
>> language to use as a complement to Java.  For performance critical
>> sections of code I use Java.  For dynamic components I use Groovy.  This
>> element of purity leads to clean and clear models of use.  This is an
>> easy sell in the training, take up and leveraging games.

I agree too, hence I wouldn't want to position this feature as
competition for Scala, Kotlin etc. Groovy should remain dynamic
focused.

Having said that I would like to be able to selectively choose a
method/class or even a method call in Groovy that should bypass MOP
calls.

I don't want to have to drop down to Java since my personal
productivity dips significantly.

I suggested at one point as a minimum (if we don't add full static
compilation) it would at least be nice to have a dot operator
equivalent that dispatches statically. Such as

foo->callMe()

We should experiment with different solutions in this area and keep
innovating. Maybe full static compilation is not required (although
static type checking I think it definitely a nice to have)

Cheers

>>
>> Turning Groovy into a mish-mash language trying to kowtow to the wants
>> of a disparate and conflicting set of requirements seems like a recipe
>> for the demise of the language.
>>
>> Groovy should not and should not even try to be a better Java.  It is a
>> symbiotic partner bringing different capabilities.  This is Groovy's
>> USP, and its sole reason for existing.
>
> Well said, I agree completely.
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>
>



--
Graeme Rocher
Grails Project Lead
SpringSource - A Division of VMware
http://www.springsource.com

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

    http://xircles.codehaus.org/manage_email


1234 ... 6
Loading...