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:

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

Re: static compilation for Groovy

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:

Re: static compilation for Groovy

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.

Re: static compilation for Groovy

+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:

Re: static compilation for Groovy

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.

Re: static compilation for Groovy

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

Re: static compilation for Groovy

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

Re: static compilation for Groovy

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.

Re: static compilation for Groovy

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