Mailing-List: contact dev-help@groovy.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@groovy.apache.org
Date: Wed, 19 Oct 2016 12:21:38 +0200 (CEST)
From: Remi Forax <forax@univ-mlv.fr>
To: dev@groovy.apache.org
Message-ID: <1778916372.1257597.1476872498892.JavaMail.zimbra@u-pem.fr>
In-Reply-To: <CADQzvm=Cb28FFwGMb3tEDBAkt6XS5_2112QoSYQ=572D2gz=3A@mail.gmail.com>
References: <1476718854771-5736169.post@n5.nabble.com> <SG2PR0301MB19516DCE3800F01D7AFB6B47A3D30@SG2PR0301MB1951.apcprd03.prod.outlook.com> <CAJ2HCd8HeBQR2aoag7X-7s0t9puddRFojhUp=bRixdXU15rfPA@mail.gmail.com> <SG2PR0301MB195175C95BCC7AC3F59B642AA3D20@SG2PR0301MB1951.apcprd03.prod.outlook.com> <CAJ2HCd8x1EF6vBMeHx_=q5e8OB7h_-r8j26eaLGDYNWH9nhpRA@mail.gmail.com> <SG2PR0301MB19516380BB8E22ED2AE68265A3D20@SG2PR0301MB1951.apcprd03.prod.outlook.com> <5806CC8E.2080308@gmx.org> <CADQzvm=Cb28FFwGMb3tEDBAkt6XS5_2112QoSYQ=572D2gz=3A@mail.gmail.com>
Subject: Re: Lambda expression for Groovy 3
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_1257596_630114099.1476872498891"
Thread-Topic: Lambda expression for Groovy 3
Thread-Index: XgbCoAGo8GhIoyRv/KM7y9QHRTjlFg==
archived-at: Wed, 19 Oct 2016 11:17:36 -0000

------=_Part_1257596_630114099.1476872498891
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Hi Cedric,=20

> De: "C=C3=A9dric Champeau" <cedric.champeau@gmail.com>
> =C3=80: dev@groovy.apache.org
> Envoy=C3=A9: Mercredi 19 Octobre 2016 09:09:51
> Objet: Re: Lambda expression for Groovy 3

> First of all, great work, Daniel ! I'm confident that making the "lambdas=
" be
> "closures" in Groovy is enough. I stated it in the past but I'm going to =
repeat
> myself here, I don't think having 2 syntax for "closures/lambdas" with sl=
ightly
> different semantics would help our users/language. That said, the static
> compiler can do better, doing escape analysis, and using "real" lambdas w=
hen
> the target bytecode is 8, as an optimization.

The main issue i see of having one semantics is that the meaning of 'this' =
in a Groovy closure means the closure itself while 'this' in a Java lambda =
means the enclosing object, so { -> this } in Groovy is a substitute to () =
-> this in Java.=20
The choice seems to be, the semantics of 'this' in a lambda in Groovy can b=
e either the same as Java so you can copy/paste a Java code and it will wor=
k as is in Groovy or the same semantics as in a Groovy closure so as you sa=
id you will not have to explain why in Groovy { -> this } and () -> this do=
 not return the same value.=20

I have no opinion about that, i let you guys decide :)=20

That said, the lambda metafactory takes a desugared lambda as argument (a p=
lain old static method, apart in corner cases), so choosing the semantics o=
f the lambda in Groovy is orthogonal to the choice of using the lambda meta=
factory or not.=20

R=C3=A9mi=20

------=_Part_1257596_630114099.1476872498891
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<html><body><div style=3D"font-family: arial, helvetica, sans-serif; font-s=
ize: 12pt; color: #000000"><div>Hi Cedric,<br></div><div><br></div><hr id=
=3D"zwchr" data-marker=3D"__DIVIDER__"><div data-marker=3D"__HEADERS__"><bl=
ockquote style=3D"border-left:2px solid #1010FF;margin-left:5px;padding-lef=
t:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;=
font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><b>De: </b>"C=C3=A9=
dric Champeau" &lt;cedric.champeau@gmail.com&gt;<br><b>=C3=80: </b>dev@groo=
vy.apache.org<br><b>Envoy=C3=A9: </b>Mercredi 19 Octobre 2016 09:09:51<br><=
b>Objet: </b>Re: Lambda expression for Groovy 3<br></blockquote></div><div =
data-marker=3D"__QUOTED_TEXT__"><blockquote style=3D"border-left:2px solid =
#1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font=
-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;f=
ont-size:12pt;"><div dir=3D"ltr">First of all, great work, Daniel ! I'm con=
fident that making the "lambdas" be "closures" in Groovy is enough. I state=
d it in the past but I'm going to repeat myself here, I don't think having =
2 syntax for "closures/lambdas" with slightly different semantics would hel=
p our users/language. That said, the static compiler can do better, doing e=
scape analysis, and using "real" lambdas when the target bytecode is 8, as =
an optimization.</div></blockquote><div><br></div><div>The main issue i see=
 of having one semantics is that the meaning of 'this' in a Groovy closure =
means the closure itself while 'this' in a Java lambda means the enclosing =
object, so { -&gt; this } in Groovy is a substitute to () -&gt; this in Jav=
a.<br data-mce-bogus=3D"1"></div><div>The choice seems to be, the semantics=
 of 'this' in a lambda in Groovy can be either the same as Java so you can =
copy/paste a Java code and it will work as is in Groovy or the same semanti=
cs as in a Groovy closure so as you said you will not have to explain why i=
n Groovy { -&gt; this } and () -&gt; this do not return the same value.<br =
data-mce-bogus=3D"1"></div><div><br data-mce-bogus=3D"1"></div><div>I have =
no opinion about that, i let you guys decide :)<br data-mce-bogus=3D"1"></d=
iv><div><br data-mce-bogus=3D"1"></div><div>That said, the lambda metafacto=
ry takes a desugared lambda as argument (a plain old static method, apart i=
n corner cases), so choosing the semantics of the lambda in Groovy is ortho=
gonal to the choice of using the lambda metafactory or not.</div><div><br d=
ata-mce-bogus=3D"1"></div><div>R=C3=A9mi<br data-mce-bogus=3D"1"></div><br =
data-mce-bogus=3D"1"></div></div></body></html>
------=_Part_1257596_630114099.1476872498891--