You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@groovy.apache.org by Daniel Sun <re...@hotmail.com> on 2017/02/07 15:00:06 UTC
答复: [VOTE] Apache Groovy Roadmap
Hi Jochen,
That’s great!
Paul and Graeme are both afraid of future breaking changes of groovy’s lambda expression, which is currently based on closure. If we could generate *real* lambda bytecode for LambdaExpression, groovy’s lambda expression will behave same with Java8’s at runtime??
Cheers,
Daniel.Sun
发件人: Jochen Theodorou [via Groovy]<ma...@n5.nabble.com>
发送时间: 2017年2月7日 22:23
收件人: Daniel Sun<ma...@hotmail.com>
主题: Re: [VOTE] Apache Groovy Roadmap
On 07.02.2017 14:44, Daniel Sun wrote:
> Hi Cédric,
>
> It seems that too many choices are a annoying problem, but I
> believe we can conquer it sooner or later ;)
> BTW, is it possible to keep groovy' lambda expression as it
> is(i.e. groovy closure with lambda syntax) but generate *real* lambda
> bytecode for
> it(https://github.com/apache/groovy/blob/parrot/src/main/org/codehaus/groovy/ast/expr/LambdaExpression.java)?
sure, you should make a visitLambdaExpression similar to
visitClosureExpression and change our visitors
bye Jochen
________________________________
If you reply to this email, your message will be added to the discussion below:
http://groovy.329449.n5.nabble.com/VOTE-Apache-Groovy-Roadmap-tp5738250p5738471.html
To unsubscribe from [VOTE] Apache Groovy Roadmap, click here<http://groovy.329449.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=5738250&code=cmVhbGJsdWVzdW5AaG90bWFpbC5jb218NTczODI1MHwxMTQ2MjE4MjI1>.
NAML<http://groovy.329449.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
--
View this message in context: http://groovy.329449.n5.nabble.com/VOTE-Apache-Groovy-Roadmap-tp5738250p5738477.html
Sent from the Groovy Dev mailing list archive at Nabble.com.
答复: Lambda vs. Closure
Posted by Daniel Sun <re...@hotmail.com>.
Hi Jochen,
Gotcha 😊
BTW, Generating the real lambda needs type information which is only available in the static compilation mode…so it’s impossible to have universal version of lambda if we want to implement the real lambda.
Cheers,
Daniel.Sun
发件人: Jochen Theodorou [via Groovy]<ma...@n5.nabble.com>
发送时间: 2017年2月8日 0:53
收件人: Daniel Sun<ma...@hotmail.com>
主题: Re: Lambda vs. Closure
On 07.02.2017 16:44, Jesper Steen Møller wrote:
[...]
> Generating faster/tighter code for lambdas (or even closures) can be
> implemented as a separate task, the two aren't really interconnected,
> since the Groovy closure is so versatile to begin with.
The problem is that Closure has delegates, owners and several other
things, that make no sense for lambdas in the sense of Java. In other
words: Closure does too much and is too heavy weight
bye Jochen
________________________________
If you reply to this email, your message will be added to the discussion below:
http://groovy.329449.n5.nabble.com/VOTE-Apache-Groovy-Roadmap-tp5738250p5738489.html
To unsubscribe from [VOTE] Apache Groovy Roadmap, click here<http://groovy.329449.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=5738250&code=cmVhbGJsdWVzdW5AaG90bWFpbC5jb218NTczODI1MHwxMTQ2MjE4MjI1>.
NAML<http://groovy.329449.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
--
View this message in context: http://groovy.329449.n5.nabble.com/VOTE-Apache-Groovy-Roadmap-tp5738250p5738490.html
Sent from the Groovy Dev mailing list archive at Nabble.com.
Re: Lambda vs. Closure
Posted by Jochen Theodorou <bl...@gmx.org>.
On 07.02.2017 16:44, Jesper Steen M�ller wrote:
[...]
> Generating faster/tighter code for lambdas (or even closures) can be
> implemented as a separate task, the two aren't really interconnected,
> since the Groovy closure is so versatile to begin with.
The problem is that Closure has delegates, owners and several other
things, that make no sense for lambdas in the sense of Java. In other
words: Closure does too much and is too heavy weight
bye Jochen
答复: Lambda vs. Closure (was: [VOTE] Apache Groovy Roadmap)
Posted by Daniel Sun <re...@hotmail.com>.
Hi Jesper,
I’ve opened a new vote for the implementation of lambda expression, you can find it in the dev-list 😉
Cheers,
Daniel.Sun
发件人: 孙 岚<ma...@hotmail.com>
发送时间: 2017年2月7日 23:49
收件人: Jesper Steen Møller [via Groovy]<ma...@n5.nabble.com>
主题: 答复: Lambda vs. Closure (was: [VOTE] Apache Groovy Roadmap)
Hi Jesper,
Gotcha 😊
For me, I don’t like two versions of lambda expression… it will confuse developers.
Cheers,
Daniel.Sun
发件人: Jesper Steen Møller [via Groovy]<ma...@n5.nabble.com>
发送时间: 2017年2月7日 23:44
收件人: Daniel Sun<ma...@hotmail.com>
主题: Re: Lambda vs. Closure (was: [VOTE] Apache Groovy Roadmap)
On 7 Feb 2017, at 16.27, Daniel Sun <[hidden email]</user/SendEmail.jtp?type=node&node=5738482&i=0>> wrote:
To fully support *real* lambda expression, (to be honest)currently I have no idea how to generate bytecode for it. In addition, supporting Static Compilation will be another big work…
A real lambda expression is implemented in Java as an invokedynamic call which makes use of a bootstrap method calling into a class called the LambdaMetafactory (https://docs.oracle.com/javase/8/docs/api/java/lang/invoke/LambdaMetafactory.html) , and puts the body of the lambda expression into a hidden method on the class. The LambdaMetafactory sets up the magic class which holds any escaped variables and implements the functional interface. To work, it requires EXACT type information, so it's only possible to do this in static compilation.
1. For instance, we could warn the user if the lambda referred to 'this' or 'super' directly.
I think ‘this’ and ‘super’ can be referred but developers should not change its resolve strategy, so we can forbidden the scenario by syntax check 😊
I would like to open a new discussion based on our discussion in the dev-list later and wish others would think same with us to accept the closure with lambda syntax
I'm not sure why we need a separate discussion.
We have a basic choice: 1) Use Java-lambda semantics or 2) Groovy-closure semantics. As a variation on 2, we can add some help for people pasting Java code into a Groovy program.
Generating faster/tighter code for lambdas (or even closures) can be implemented as a separate task, the two aren't really interconnected, since the Groovy closure is so versatile to begin with.
-Jesper
发件人: <a href="x-msg://13/user/SendEmail.jtp?type=node&node=5738481&i=0" target="_top" rel="nofollow" link="external" class="">[hidden email]
发送时间: 2017年2月7日 23:10
收件人: <a href="x-msg://13/user/SendEmail.jtp?type=node&node=5738481&i=1" target="_top" rel="nofollow" link="external" class="">[hidden email]
主题: Lambda vs. Closure (was: [VOTE] Apache Groovy Roadmap)
(changing the subject so we don't disrupt the main discussion)
Not quite 😔
The changes in Java to support Lambdas are much deeper than just how the Metafactory is invokedynamic'ed, as it changes how type inference and overload resolution is done. Same as with the issues we discussed a while back around method references: Supporting Java8 semantics in the Groovy compiler is a very big task, as we just don't have the type information available.
I would much rather suggest supporting the lambda syntax with groovy semantics, but add warnings if we detect that the code may rely on Java lambda semantics. For instance, we could warn the user if the lambda referred to 'this' or 'super' directly.
-Jesper
On 7 Feb 2017, at 16.00, Daniel Sun <<a href="x-msg://13/user/SendEmail.jtp?type=node&node=5738478&i=0" target="_top" rel="nofollow" link="external" class="">[hidden email]> wrote:
Hi Jochen,
That’s great!
Paul and Graeme are both afraid of future breaking changes of groovy’s lambda expression, which is currently based on closure. If we could generate *real* lambda bytecode for LambdaExpression, groovy’s lambda expression will behave same with Java8’s at runtime😊
Cheers,
Daniel.Sun
发件人: <a href="<a href="x-msg://12/user/SendEmail.jtp?type=node&amp;node=5738477&amp;i=0" class="">x-msg://12/user/SendEmail.jtp?type=node&node=5738477&i=0" target="_top" rel="nofollow" link="external" class="">[hidden email]
发送时间: 2017年2月7日 22:23
收件人: <a href="<a href="x-msg://12/user/SendEmail.jtp?type=node&amp;node=5738477&amp;i=1" class="">x-msg://12/user/SendEmail.jtp?type=node&node=5738477&i=1" target="_top" rel="nofollow" link="external" class="">[hidden email]
主题: Re: [VOTE] Apache Groovy Roadmap
On 07.02.2017 14:44, Daniel Sun wrote:
> Hi Cédric,
>
> It seems that too many choices are a annoying problem, but I
> believe we can conquer it sooner or later ;)
> BTW, is it possible to keep groovy' lambda expression as it
> is(i.e. groovy closure with lambda syntax) but generate *real* lambda
> bytecode for
> it(https://github.com/apache/groovy/blob/parrot/src/main/org/codehaus/groovy/ast/expr/LambdaExpression.java)?
sure, you should make a visitLambdaExpression similar to
visitClosureExpression and change our visitors
bye Jochen
If you reply to this email, your message will be added to the discussion below:
http://groovy.329449.n5.nabble.com/VOTE-Apache-Groovy-Roadmap-tp5738250p5738471.html
To unsubscribe from [VOTE] Apache Groovy Roadmap, click here.
NAML<http://groovy.329449.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
View this message in context: 答复: [VOTE] Apache Groovy Roadmap<http://groovy.329449.n5.nabble.com/VOTE-Apache-Groovy-Roadmap-tp5738250p5738477.html>
Sent from the Groovy Dev mailing list archive<http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html> at Nabble.com<http://nabble.com/>.
If you reply to this email, your message will be added to the discussion below:
http://groovy.329449.n5.nabble.com/VOTE-Apache-Groovy-Roadmap-tp5738250p5738478.html
To unsubscribe from [VOTE] Apache Groovy Roadmap, click here.
NAML<http://groovy.329449.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
View this message in context: 答复: Lambda vs. Closure (was: [VOTE] Apache Groovy Roadmap)<http://groovy.329449.n5.nabble.com/VOTE-Apache-Groovy-Roadmap-tp5738250p5738481.html>
Sent from the Groovy Dev mailing list archive<http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html> at Nabble.com<http://Nabble.com>.
If you reply to this email, your message will be added to the discussion below:
http://groovy.329449.n5.nabble.com/VOTE-Apache-Groovy-Roadmap-tp5738250p5738482.html
To unsubscribe from [VOTE] Apache Groovy Roadmap, click here<http://groovy.329449.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=5738250&code=cmVhbGJsdWVzdW5AaG90bWFpbC5jb218NTczODI1MHwxMTQ2MjE4MjI1>.
NAML<http://groovy.329449.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
255BE998123446CE821944FE06B16C99.png (190 bytes) <http://groovy.329449.n5.nabble.com/attachment/5738487/0/255BE998123446CE821944FE06B16C99.png>
F479E271DD254A61A9EF12764CF76C5A.png (206 bytes) <http://groovy.329449.n5.nabble.com/attachment/5738487/1/F479E271DD254A61A9EF12764CF76C5A.png>
E7B2A2AE4D2C495D89D99052E580861B.png (202 bytes) <http://groovy.329449.n5.nabble.com/attachment/5738487/2/E7B2A2AE4D2C495D89D99052E580861B.png>
D4297BE0AA2D4CA59AA5F5D147DBB27A.png (210 bytes) <http://groovy.329449.n5.nabble.com/attachment/5738487/3/D4297BE0AA2D4CA59AA5F5D147DBB27A.png>
--
View this message in context: http://groovy.329449.n5.nabble.com/VOTE-Apache-Groovy-Roadmap-tp5738250p5738487.html
Sent from the Groovy Dev mailing list archive at Nabble.com.
Re: 答复: Lambda vs. Closure
Posted by Jochen Theodorou <bl...@gmx.org>.
On 07.02.2017 17:39, Daniel Sun wrote:
[...]
>
> * We have a basic choice: 1) Use Java-lambda semantics or 2)
> Groovy-closure semantics. As a variation on 2, we can add some help
> for people pasting Java code into a Groovy program.
>
>
> Agreed.
hmm... let me add some thoughts to this...
I see a lambda as a kind of lightweight proxy, that provides an
implementation for a series of functional interfaces. In that matter
they are like "closure as SomeFunctionalInterface", only that our
solution is not lightweight.
Since we know the internals we can ignore the proxy facade and directly
use the method that realizes the proxy. All that is then required is to
transform call arguments to the types the implementing method needs.
It would be very possible to use the LambdaMetaFactory for for example
"closure as SomeFunctionalInterface".
At the same time we can provide our own LambdaMetaFactory (ignoring
Java9 problems). The "problem" is the identity of the implementing
method and what signature you use for it. In dynamic Groovy you can go
with object for most parts and have no trouble.
What we are really missing is the ability to decide at compile time
between two overloaded methods each taking functional interfaces. Only
this requires extended static analysis. If we delay that part to
runtime, like we do today for SAM Closures, then we do not need this as
long as the interfaces differ on a level recognizable after type erasure.
if we have for example one method taking List<A> and another taking
List<B> as parameter type for the method of the functional interface,
then we really really need a static analysis.
In the end that boils for me down to:
* dynamic Groovy can most probably not use LambdaMetaFactory and could
probably use the already existing ifrastructure the invokedynamic port
provides.
* static Groovy can use LambdaMetaFactory but needs to be improved on
the compiler level
bye Jochen
答复: Lambda vs. Closure (was: [VOTE] Apache Groovy Roadmap)
Posted by Daniel Sun <re...@hotmail.com>.
Hi Jesper,
* I'm not sure why we need a separate discussion.
If most of us want the current lambda expression(based on closure), we need not thrash out how to implement Java-lambda semantics 😉
* We have a basic choice: 1) Use Java-lambda semantics or 2) Groovy-closure semantics. As a variation on 2, we can add some help for people pasting Java code into a Groovy program.
Agreed.
P.S. I have not seen your above words…
Cheers,
Daniel.Sun
发件人: 孙 岚<ma...@hotmail.com>
发送时间: 2017年2月7日 23:49
收件人: Jesper Steen Møller [via Groovy]<ma...@n5.nabble.com>
主题: 答复: Lambda vs. Closure (was: [VOTE] Apache Groovy Roadmap)
Hi Jesper,
Gotcha 😊
For me, I don’t like two versions of lambda expression… it will confuse developers.
Cheers,
Daniel.Sun
发件人: Jesper Steen Møller [via Groovy]<ma...@n5.nabble.com>
发送时间: 2017年2月7日 23:44
收件人: Daniel Sun<ma...@hotmail.com>
主题: Re: Lambda vs. Closure (was: [VOTE] Apache Groovy Roadmap)
On 7 Feb 2017, at 16.27, Daniel Sun <[hidden email]</user/SendEmail.jtp?type=node&node=5738482&i=0>> wrote:
To fully support *real* lambda expression, (to be honest)currently I have no idea how to generate bytecode for it. In addition, supporting Static Compilation will be another big work…
A real lambda expression is implemented in Java as an invokedynamic call which makes use of a bootstrap method calling into a class called the LambdaMetafactory (https://docs.oracle.com/javase/8/docs/api/java/lang/invoke/LambdaMetafactory.html) , and puts the body of the lambda expression into a hidden method on the class. The LambdaMetafactory sets up the magic class which holds any escaped variables and implements the functional interface. To work, it requires EXACT type information, so it's only possible to do this in static compilation.
* For instance, we could warn the user if the lambda referred to 'this' or 'super' directly.
I think ‘this’ and ‘super’ can be referred but developers should not change its resolve strategy, so we can forbidden the scenario by syntax check 😊
I would like to open a new discussion based on our discussion in the dev-list later and wish others would think same with us to accept the closure with lambda syntax
I'm not sure why we need a separate discussion.
We have a basic choice: 1) Use Java-lambda semantics or 2) Groovy-closure semantics. As a variation on 2, we can add some help for people pasting Java code into a Groovy program.
Generating faster/tighter code for lambdas (or even closures) can be implemented as a separate task, the two aren't really interconnected, since the Groovy closure is so versatile to begin with.
-Jesper
发件人: <a href="x-msg://13/user/SendEmail.jtp?type=node&node=5738481&i=0" target="_top" rel="nofollow" link="external" class="">[hidden email]
发送时间: 2017年2月7日 23:10
收件人: <a href="x-msg://13/user/SendEmail.jtp?type=node&node=5738481&i=1" target="_top" rel="nofollow" link="external" class="">[hidden email]
主题: Lambda vs. Closure (was: [VOTE] Apache Groovy Roadmap)
(changing the subject so we don't disrupt the main discussion)
Not quite 😔
The changes in Java to support Lambdas are much deeper than just how the Metafactory is invokedynamic'ed, as it changes how type inference and overload resolution is done. Same as with the issues we discussed a while back around method references: Supporting Java8 semantics in the Groovy compiler is a very big task, as we just don't have the type information available.
I would much rather suggest supporting the lambda syntax with groovy semantics, but add warnings if we detect that the code may rely on Java lambda semantics. For instance, we could warn the user if the lambda referred to 'this' or 'super' directly.
-Jesper
On 7 Feb 2017, at 16.00, Daniel Sun <<a href="x-msg://13/user/SendEmail.jtp?type=node&node=5738478&i=0" target="_top" rel="nofollow" link="external" class="">[hidden email]> wrote:
Hi Jochen,
That’s great!
Paul and Graeme are both afraid of future breaking changes of groovy’s lambda expression, which is currently based on closure. If we could generate *real* lambda bytecode for LambdaExpression, groovy’s lambda expression will behave same with Java8’s at runtime😊
Cheers,
Daniel.Sun
发件人: <a href="<a href="x-msg://12/user/SendEmail.jtp?type=node&amp;node=5738477&amp;i=0" class="">x-msg://12/user/SendEmail.jtp?type=node&node=5738477&i=0" target="_top" rel="nofollow" link="external" class="">[hidden email]
发送时间: 2017年2月7日 22:23
收件人: <a href="<a href="x-msg://12/user/SendEmail.jtp?type=node&amp;node=5738477&amp;i=1" class="">x-msg://12/user/SendEmail.jtp?type=node&node=5738477&i=1" target="_top" rel="nofollow" link="external" class="">[hidden email]
主题: Re: [VOTE] Apache Groovy Roadmap
On 07.02.2017 14:44, Daniel Sun wrote:
> Hi Cédric,
>
> It seems that too many choices are a annoying problem, but I
> believe we can conquer it sooner or later ;)
> BTW, is it possible to keep groovy' lambda expression as it
> is(i.e. groovy closure with lambda syntax) but generate *real* lambda
> bytecode for
> it(https://github.com/apache/groovy/blob/parrot/src/main/org/codehaus/groovy/ast/expr/LambdaExpression.java)?
sure, you should make a visitLambdaExpression similar to
visitClosureExpression and change our visitors
bye Jochen
________________________________
If you reply to this email, your message will be added to the discussion below:
http://groovy.329449.n5.nabble.com/VOTE-Apache-Groovy-Roadmap-tp5738250p5738471.html
To unsubscribe from [VOTE] Apache Groovy Roadmap, click here.
NAML<http://groovy.329449.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
________________________________
View this message in context: 答复: [VOTE] Apache Groovy Roadmap<http://groovy.329449.n5.nabble.com/VOTE-Apache-Groovy-Roadmap-tp5738250p5738477.html>
Sent from the Groovy Dev mailing list archive<http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html> at Nabble.com<http://nabble.com/>.
________________________________
If you reply to this email, your message will be added to the discussion below:
http://groovy.329449.n5.nabble.com/VOTE-Apache-Groovy-Roadmap-tp5738250p5738478.html
To unsubscribe from [VOTE] Apache Groovy Roadmap, click here.
NAML<http://groovy.329449.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
________________________________
View this message in context: 答复: Lambda vs. Closure (was: [VOTE] Apache Groovy Roadmap)<http://groovy.329449.n5.nabble.com/VOTE-Apache-Groovy-Roadmap-tp5738250p5738481.html>
Sent from the Groovy Dev mailing list archive<http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html> at Nabble.com<http://Nabble.com>.
________________________________
If you reply to this email, your message will be added to the discussion below:
http://groovy.329449.n5.nabble.com/VOTE-Apache-Groovy-Roadmap-tp5738250p5738482.html
To unsubscribe from [VOTE] Apache Groovy Roadmap, click here<http://groovy.329449.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=5738250&code=cmVhbGJsdWVzdW5AaG90bWFpbC5jb218NTczODI1MHwxMTQ2MjE4MjI1>.
NAML<http://groovy.329449.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
--
View this message in context: http://groovy.329449.n5.nabble.com/VOTE-Apache-Groovy-Roadmap-tp5738250p5738488.html
Sent from the Groovy Dev mailing list archive at Nabble.com.
答复: Lambda vs. Closure (was: [VOTE] Apache Groovy Roadmap)
Posted by Daniel Sun <re...@hotmail.com>.
Hi Jesper,
Gotcha 😊
For me, I don’t like two versions of lambda expression… it will confuse developers.
Cheers,
Daniel.Sun
发件人: Jesper Steen Møller [via Groovy]<ma...@n5.nabble.com>
发送时间: 2017年2月7日 23:44
收件人: Daniel Sun<ma...@hotmail.com>
主题: Re: Lambda vs. Closure (was: [VOTE] Apache Groovy Roadmap)
On 7 Feb 2017, at 16.27, Daniel Sun <[hidden email]</user/SendEmail.jtp?type=node&node=5738482&i=0>> wrote:
To fully support *real* lambda expression, (to be honest)currently I have no idea how to generate bytecode for it. In addition, supporting Static Compilation will be another big work…
A real lambda expression is implemented in Java as an invokedynamic call which makes use of a bootstrap method calling into a class called the LambdaMetafactory (https://docs.oracle.com/javase/8/docs/api/java/lang/invoke/LambdaMetafactory.html) , and puts the body of the lambda expression into a hidden method on the class. The LambdaMetafactory sets up the magic class which holds any escaped variables and implements the functional interface. To work, it requires EXACT type information, so it's only possible to do this in static compilation.
* For instance, we could warn the user if the lambda referred to 'this' or 'super' directly.
I think ‘this’ and ‘super’ can be referred but developers should not change its resolve strategy, so we can forbidden the scenario by syntax check 😊
I would like to open a new discussion based on our discussion in the dev-list later and wish others would think same with us to accept the closure with lambda syntax
I'm not sure why we need a separate discussion.
We have a basic choice: 1) Use Java-lambda semantics or 2) Groovy-closure semantics. As a variation on 2, we can add some help for people pasting Java code into a Groovy program.
Generating faster/tighter code for lambdas (or even closures) can be implemented as a separate task, the two aren't really interconnected, since the Groovy closure is so versatile to begin with.
-Jesper
发件人: <a href="x-msg://13/user/SendEmail.jtp?type=node&node=5738481&i=0" target="_top" rel="nofollow" link="external" class="">[hidden email]
发送时间: 2017年2月7日 23:10
收件人: <a href="x-msg://13/user/SendEmail.jtp?type=node&node=5738481&i=1" target="_top" rel="nofollow" link="external" class="">[hidden email]
主题: Lambda vs. Closure (was: [VOTE] Apache Groovy Roadmap)
(changing the subject so we don't disrupt the main discussion)
Not quite 😔
The changes in Java to support Lambdas are much deeper than just how the Metafactory is invokedynamic'ed, as it changes how type inference and overload resolution is done. Same as with the issues we discussed a while back around method references: Supporting Java8 semantics in the Groovy compiler is a very big task, as we just don't have the type information available.
I would much rather suggest supporting the lambda syntax with groovy semantics, but add warnings if we detect that the code may rely on Java lambda semantics. For instance, we could warn the user if the lambda referred to 'this' or 'super' directly.
-Jesper
On 7 Feb 2017, at 16.00, Daniel Sun <<a href="x-msg://13/user/SendEmail.jtp?type=node&node=5738478&i=0" target="_top" rel="nofollow" link="external" class="">[hidden email]> wrote:
Hi Jochen,
That’s great!
Paul and Graeme are both afraid of future breaking changes of groovy’s lambda expression, which is currently based on closure. If we could generate *real* lambda bytecode for LambdaExpression, groovy’s lambda expression will behave same with Java8’s at runtime😊
Cheers,
Daniel.Sun
发件人: <a href="<a href="x-msg://12/user/SendEmail.jtp?type=node&amp;node=5738477&amp;i=0" class="">x-msg://12/user/SendEmail.jtp?type=node&node=5738477&i=0" target="_top" rel="nofollow" link="external" class="">[hidden email]
发送时间: 2017年2月7日 22:23
收件人: <a href="<a href="x-msg://12/user/SendEmail.jtp?type=node&amp;node=5738477&amp;i=1" class="">x-msg://12/user/SendEmail.jtp?type=node&node=5738477&i=1" target="_top" rel="nofollow" link="external" class="">[hidden email]
主题: Re: [VOTE] Apache Groovy Roadmap
On 07.02.2017 14:44, Daniel Sun wrote:
> Hi Cédric,
>
> It seems that too many choices are a annoying problem, but I
> believe we can conquer it sooner or later ;)
> BTW, is it possible to keep groovy' lambda expression as it
> is(i.e. groovy closure with lambda syntax) but generate *real* lambda
> bytecode for
> it(https://github.com/apache/groovy/blob/parrot/src/main/org/codehaus/groovy/ast/expr/LambdaExpression.java)?
sure, you should make a visitLambdaExpression similar to
visitClosureExpression and change our visitors
bye Jochen
________________________________
If you reply to this email, your message will be added to the discussion below:
http://groovy.329449.n5.nabble.com/VOTE-Apache-Groovy-Roadmap-tp5738250p5738471.html
To unsubscribe from [VOTE] Apache Groovy Roadmap, click here.
NAML<http://groovy.329449.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
________________________________
View this message in context: 答复: [VOTE] Apache Groovy Roadmap<http://groovy.329449.n5.nabble.com/VOTE-Apache-Groovy-Roadmap-tp5738250p5738477.html>
Sent from the Groovy Dev mailing list archive<http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html> at Nabble.com<http://nabble.com/>.
________________________________
If you reply to this email, your message will be added to the discussion below:
http://groovy.329449.n5.nabble.com/VOTE-Apache-Groovy-Roadmap-tp5738250p5738478.html
To unsubscribe from [VOTE] Apache Groovy Roadmap, click here.
NAML<http://groovy.329449.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
________________________________
View this message in context: 答复: Lambda vs. Closure (was: [VOTE] Apache Groovy Roadmap)<http://groovy.329449.n5.nabble.com/VOTE-Apache-Groovy-Roadmap-tp5738250p5738481.html>
Sent from the Groovy Dev mailing list archive<http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html> at Nabble.com<http://Nabble.com>.
________________________________
If you reply to this email, your message will be added to the discussion below:
http://groovy.329449.n5.nabble.com/VOTE-Apache-Groovy-Roadmap-tp5738250p5738482.html
To unsubscribe from [VOTE] Apache Groovy Roadmap, click here<http://groovy.329449.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=5738250&code=cmVhbGJsdWVzdW5AaG90bWFpbC5jb218NTczODI1MHwxMTQ2MjE4MjI1>.
NAML<http://groovy.329449.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
--
View this message in context: http://groovy.329449.n5.nabble.com/VOTE-Apache-Groovy-Roadmap-tp5738250p5738484.html
Sent from the Groovy Dev mailing list archive at Nabble.com.
Re: Lambda vs. Closure (was: [VOTE] Apache Groovy Roadmap)
Posted by Jesper Steen Møller <je...@selskabet.org>.
> On 7 Feb 2017, at 16.27, Daniel Sun <re...@hotmail.com> wrote:
> To fully support *real* lambda expression, (to be honest)currently I have no idea how to generate bytecode for it. In addition, supporting Static Compilation will be another big work…
>
>
A real lambda expression is implemented in Java as an invokedynamic call which makes use of a bootstrap method calling into a class called the LambdaMetafactory (https://docs.oracle.com/javase/8/docs/api/java/lang/invoke/LambdaMetafactory.html <https://docs.oracle.com/javase/8/docs/api/java/lang/invoke/LambdaMetafactory.html>) , and puts the body of the lambda expression into a hidden method on the class. The LambdaMetafactory sets up the magic class which holds any escaped variables and implements the functional interface. To work, it requires EXACT type information, so it's only possible to do this in static compilation.
>
>
> For instance, we could warn the user if the lambda referred to 'this' or 'super' directly.
> I think ‘this’ and ‘super’ can be referred but developers should not change its resolve strategy, so we can forbidden the scenario by syntax check 😊
>
>
>
> I would like to open a new discussion based on our discussion in the dev-list later and wish others would think same with us to accept the closure with lambda syntax
>
>
I'm not sure why we need a separate discussion.
We have a basic choice: 1) Use Java-lambda semantics or 2) Groovy-closure semantics. As a variation on 2, we can add some help for people pasting Java code into a Groovy program.
Generating faster/tighter code for lambdas (or even closures) can be implemented as a separate task, the two aren't really interconnected, since the Groovy closure is so versatile to begin with.
-Jesper
>
>
> 发件人: [hidden email] <x-msg://13/user/SendEmail.jtp?type=node&node=5738481&i=0>
> 发送时间: 2017年2月7日 23:10
> 收件人: [hidden email] <x-msg://13/user/SendEmail.jtp?type=node&node=5738481&i=1>
> 主题: Lambda vs. Closure (was: [VOTE] Apache Groovy Roadmap)
>
>
>
> (changing the subject so we don't disrupt the main discussion)
>
> Not quite 😔
>
> The changes in Java to support Lambdas are much deeper than just how the Metafactory is invokedynamic'ed, as it changes how type inference and overload resolution is done. Same as with the issues we discussed a while back around method references: Supporting Java8 semantics in the Groovy compiler is a very big task, as we just don't have the type information available.
>
> I would much rather suggest supporting the lambda syntax with groovy semantics, but add warnings if we detect that the code may rely on Java lambda semantics. For instance, we could warn the user if the lambda referred to 'this' or 'super' directly.
>
> -Jesper
>
>> On 7 Feb 2017, at 16.00, Daniel Sun <[hidden email] <x-msg://13/user/SendEmail.jtp?type=node&node=5738478&i=0>> wrote:
>>
>> Hi Jochen,
>>
>>
>>
>> That’s great!
>>
>> Paul and Graeme are both afraid of future breaking changes of groovy’s lambda expression, which is currently based on closure. If we could generate *real* lambda bytecode for LambdaExpression, groovy’s lambda expression will behave same with Java8’s at runtime😊
>>
>>
>>
>> Cheers,
>>
>> Daniel.Sun
>>
>>
>>
>> 发件人: <a href="x-msg://12/user/SendEmail.jtp?type=node&node=5738477&i=0" target="_top" rel="nofollow" link="external" class="">[hidden email]
>> 发送时间: 2017年2月7日 22:23
>> 收件人: <a href="x-msg://12/user/SendEmail.jtp?type=node&node=5738477&i=1" target="_top" rel="nofollow" link="external" class="">[hidden email]
>> 主题: Re: [VOTE] Apache Groovy Roadmap
>>
>>
>>
>>
>>
>> On 07.02.2017 14:44, Daniel Sun wrote:
>> > Hi Cédric,
>> >
>> > It seems that too many choices are a annoying problem, but I
>> > believe we can conquer it sooner or later ;)
>> > BTW, is it possible to keep groovy' lambda expression as it
>> > is(i.e. groovy closure with lambda syntax) but generate *real* lambda
>> > bytecode for
>> > it(https://github.com/apache/groovy/blob/parrot/src/main/org/codehaus/groovy/ast/expr/LambdaExpression.java <https://github.com/apache/groovy/blob/parrot/src/main/org/codehaus/groovy/ast/expr/LambdaExpression.java>)?
>>
>> sure, you should make a visitLambdaExpression similar to
>> visitClosureExpression and change our visitors
>>
>> bye Jochen
>>
>>
>> If you reply to this email, your message will be added to the discussion below:
>> http://groovy.329449.n5.nabble.com/VOTE-Apache-Groovy-Roadmap-tp5738250p5738471.html <http://groovy.329449.n5.nabble.com/VOTE-Apache-Groovy-Roadmap-tp5738250p5738471.html>
>> To unsubscribe from [VOTE] Apache Groovy Roadmap, click here <applewebdata://33D9FFB8-25E8-43A3-B0D7-C189440ABA6C>.
>> NAML <http://groovy.329449.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
>> View this message in context: 答复: [VOTE] Apache Groovy Roadmap <http://groovy.329449.n5.nabble.com/VOTE-Apache-Groovy-Roadmap-tp5738250p5738477.html>
>> Sent from the Groovy Dev mailing list archive <http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html> at Nabble.com <http://nabble.com/>.
>
>
>
> If you reply to this email, your message will be added to the discussion below:
> http://groovy.329449.n5.nabble.com/VOTE-Apache-Groovy-Roadmap-tp5738250p5738478.html <http://groovy.329449.n5.nabble.com/VOTE-Apache-Groovy-Roadmap-tp5738250p5738478.html>
> To unsubscribe from [VOTE] Apache Groovy Roadmap, click here <applewebdata://33D9FFB8-25E8-43A3-B0D7-C189440ABA6C>.
> NAML <http://groovy.329449.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
> View this message in context: 答复: Lambda vs. Closure (was: [VOTE] Apache Groovy Roadmap) <http://groovy.329449.n5.nabble.com/VOTE-Apache-Groovy-Roadmap-tp5738250p5738481.html>
> Sent from the Groovy Dev mailing list archive <http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html> at Nabble.com.
答复: Lambda vs. Closure (was: [VOTE] Apache Groovy Roadmap)
Posted by Daniel Sun <re...@hotmail.com>.
Hi Jesper,
To fully support *real* lambda expression, (to be honest)currently I have no idea how to generate bytecode for it. In addition, supporting Static Compilation will be another big work…
* For instance, we could warn the user if the lambda referred to 'this' or 'super' directly.
I think ‘this’ and ‘super’ can be referred but developers should not change its resolve strategy, so we can forbidden the scenario by syntax check 😊
I would like to open a new discussion based on our discussion in the dev-list later and wish others would think same with us to accept the closure with lambda syntax
Cheers,
Daniel.Sun
发件人: Jesper Steen Møller [via Groovy]<ma...@n5.nabble.com>
发送时间: 2017年2月7日 23:10
收件人: Daniel Sun<ma...@hotmail.com>
主题: Lambda vs. Closure (was: [VOTE] Apache Groovy Roadmap)
(changing the subject so we don't disrupt the main discussion)
Not quite 😔
The changes in Java to support Lambdas are much deeper than just how the Metafactory is invokedynamic'ed, as it changes how type inference and overload resolution is done. Same as with the issues we discussed a while back around method references: Supporting Java8 semantics in the Groovy compiler is a very big task, as we just don't have the type information available.
I would much rather suggest supporting the lambda syntax with groovy semantics, but add warnings if we detect that the code may rely on Java lambda semantics. For instance, we could warn the user if the lambda referred to 'this' or 'super' directly.
-Jesper
On 7 Feb 2017, at 16.00, Daniel Sun <[hidden email]</user/SendEmail.jtp?type=node&node=5738478&i=0>> wrote:
Hi Jochen,
That’s great!
Paul and Graeme are both afraid of future breaking changes of groovy’s lambda expression, which is currently based on closure. If we could generate *real* lambda bytecode for LambdaExpression, groovy’s lambda expression will behave same with Java8’s at runtime😊
Cheers,
Daniel.Sun
发件人: <a href="x-msg://12/user/SendEmail.jtp?type=node&node=5738477&i=0" target="_top" rel="nofollow" link="external" class="">[hidden email]
发送时间: 2017年2月7日 22:23
收件人: <a href="x-msg://12/user/SendEmail.jtp?type=node&node=5738477&i=1" target="_top" rel="nofollow" link="external" class="">[hidden email]
主题: Re: [VOTE] Apache Groovy Roadmap
On 07.02.2017 14:44, Daniel Sun wrote:
> Hi Cédric,
>
> It seems that too many choices are a annoying problem, but I
> believe we can conquer it sooner or later ;)
> BTW, is it possible to keep groovy' lambda expression as it
> is(i.e. groovy closure with lambda syntax) but generate *real* lambda
> bytecode for
> it(https://github.com/apache/groovy/blob/parrot/src/main/org/codehaus/groovy/ast/expr/LambdaExpression.java)?
sure, you should make a visitLambdaExpression similar to
visitClosureExpression and change our visitors
bye Jochen
________________________________
If you reply to this email, your message will be added to the discussion below:
http://groovy.329449.n5.nabble.com/VOTE-Apache-Groovy-Roadmap-tp5738250p5738471.html
To unsubscribe from [VOTE] Apache Groovy Roadmap, click here.
NAML<http://groovy.329449.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
________________________________
View this message in context: 答复: [VOTE] Apache Groovy Roadmap<http://groovy.329449.n5.nabble.com/VOTE-Apache-Groovy-Roadmap-tp5738250p5738477.html>
Sent from the Groovy Dev mailing list archive<http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html> at Nabble.com<http://Nabble.com>.
________________________________
If you reply to this email, your message will be added to the discussion below:
http://groovy.329449.n5.nabble.com/VOTE-Apache-Groovy-Roadmap-tp5738250p5738478.html
To unsubscribe from [VOTE] Apache Groovy Roadmap, click here<http://groovy.329449.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=5738250&code=cmVhbGJsdWVzdW5AaG90bWFpbC5jb218NTczODI1MHwxMTQ2MjE4MjI1>.
NAML<http://groovy.329449.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
--
View this message in context: http://groovy.329449.n5.nabble.com/VOTE-Apache-Groovy-Roadmap-tp5738250p5738481.html
Sent from the Groovy Dev mailing list archive at Nabble.com.
Lambda vs. Closure (was: [VOTE] Apache Groovy Roadmap)
Posted by Jesper Steen Møller <je...@selskabet.org>.
(changing the subject so we don't disrupt the main discussion)
Not quite 😔
The changes in Java to support Lambdas are much deeper than just how the Metafactory is invokedynamic'ed, as it changes how type inference and overload resolution is done. Same as with the issues we discussed a while back around method references: Supporting Java8 semantics in the Groovy compiler is a very big task, as we just don't have the type information available.
I would much rather suggest supporting the lambda syntax with groovy semantics, but add warnings if we detect that the code may rely on Java lambda semantics. For instance, we could warn the user if the lambda referred to 'this' or 'super' directly.
-Jesper
> On 7 Feb 2017, at 16.00, Daniel Sun <re...@hotmail.com> wrote:
>
> Hi Jochen,
>
>
>
> That’s great!
>
> Paul and Graeme are both afraid of future breaking changes of groovy’s lambda expression, which is currently based on closure. If we could generate *real* lambda bytecode for LambdaExpression, groovy’s lambda expression will behave same with Java8’s at runtime😊
>
>
>
> Cheers,
>
> Daniel.Sun
>
>
>
> 发件人: [hidden email] <x-msg://12/user/SendEmail.jtp?type=node&node=5738477&i=0>
> 发送时间: 2017年2月7日 22:23
> 收件人: [hidden email] <x-msg://12/user/SendEmail.jtp?type=node&node=5738477&i=1>
> 主题: Re: [VOTE] Apache Groovy Roadmap
>
>
>
>
>
> On 07.02.2017 14:44, Daniel Sun wrote:
> > Hi Cédric,
> >
> > It seems that too many choices are a annoying problem, but I
> > believe we can conquer it sooner or later ;)
> > BTW, is it possible to keep groovy' lambda expression as it
> > is(i.e. groovy closure with lambda syntax) but generate *real* lambda
> > bytecode for
> > it(https://github.com/apache/groovy/blob/parrot/src/main/org/codehaus/groovy/ast/expr/LambdaExpression.java <https://github.com/apache/groovy/blob/parrot/src/main/org/codehaus/groovy/ast/expr/LambdaExpression.java>)?
>
> sure, you should make a visitLambdaExpression similar to
> visitClosureExpression and change our visitors
>
> bye Jochen
>
>
> If you reply to this email, your message will be added to the discussion below:
> http://groovy.329449.n5.nabble.com/VOTE-Apache-Groovy-Roadmap-tp5738250p5738471.html <http://groovy.329449.n5.nabble.com/VOTE-Apache-Groovy-Roadmap-tp5738250p5738471.html>
> To unsubscribe from [VOTE] Apache Groovy Roadmap, click here <applewebdata://B43F076E-4CE3-48E5-BE21-FA7C074BC8FF>.
> NAML <http://groovy.329449.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
> View this message in context: 答复: [VOTE] Apache Groovy Roadmap <http://groovy.329449.n5.nabble.com/VOTE-Apache-Groovy-Roadmap-tp5738250p5738477.html>
> Sent from the Groovy Dev mailing list archive <http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html> at Nabble.com.