Return-Path: X-Original-To: archive-asf-public-internal@cust-asf2.ponee.io Delivered-To: archive-asf-public-internal@cust-asf2.ponee.io Received: from cust-asf.ponee.io (cust-asf.ponee.io [163.172.22.183]) by cust-asf2.ponee.io (Postfix) with ESMTP id AFE55200C08 for ; Thu, 26 Jan 2017 10:33:34 +0100 (CET) Received: by cust-asf.ponee.io (Postfix) id AE71B160B4C; Thu, 26 Jan 2017 09:33:34 +0000 (UTC) Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by cust-asf.ponee.io (Postfix) with SMTP id 86553160B40 for ; Thu, 26 Jan 2017 10:33:33 +0100 (CET) Received: (qmail 40917 invoked by uid 500); 26 Jan 2017 09:33:32 -0000 Mailing-List: contact dev-help@groovy.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@groovy.apache.org Delivered-To: mailing list dev@groovy.apache.org Received: (qmail 40907 invoked by uid 99); 26 Jan 2017 09:33:32 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd2-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 26 Jan 2017 09:33:32 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd2-us-west.apache.org (ASF Mail Server at spamd2-us-west.apache.org) with ESMTP id F1D421A065B for ; Thu, 26 Jan 2017 09:33:31 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd2-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 4.693 X-Spam-Level: **** X-Spam-Status: No, score=4.693 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_REPLY=1, HTML_MESSAGE=2, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URI_HEX=1.313] autolearn=disabled Authentication-Results: spamd2-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mx1-lw-eu.apache.org ([10.40.0.8]) by localhost (spamd2-us-west.apache.org [10.40.0.9]) (amavisd-new, port 10024) with ESMTP id 1-7l57nx30sU for ; Thu, 26 Jan 2017 09:33:29 +0000 (UTC) Received: from mail-wm0-f44.google.com (mail-wm0-f44.google.com [74.125.82.44]) by mx1-lw-eu.apache.org (ASF Mail Server at mx1-lw-eu.apache.org) with ESMTPS id A37F95F472 for ; Thu, 26 Jan 2017 09:33:28 +0000 (UTC) Received: by mail-wm0-f44.google.com with SMTP id r144so73737465wme.1 for ; Thu, 26 Jan 2017 01:33:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=6eV93NwvGvQhsjj4pzmY5S88UIGl5IM2uY38ks//DKM=; b=tcLEk/17CrGUTlF5zMi+Zsru5FD/dr0A4v+1lu2Qj5hLFRz31eYsMLzEa5J2FmyCE1 lNct8972rOpcPy2q1d+8duxAGWCw3StTVSycBFkIKqRkYYLF+WaupFiW33pI8X12Fw1a 46eUEGXrKkXRRKjzkYK2BNX4wDxshVKc2JoFI+JpCZPEm9/kvfaDMSO5UU9k1TsBnbIo YBdSElpt+cE1cdhHZdF3kLR/ujD/hcAVqRhQBHWpjEAp5YnPwXjmY1lSPFm32oJfa5N0 /k6GDy5K3MWOgDAYhVf26tK8erDpJ8axxVrqgXgtJbxY1b1j62KyV4VWQjpQwnWknx7n hhrw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=6eV93NwvGvQhsjj4pzmY5S88UIGl5IM2uY38ks//DKM=; b=K5pOigw5swfpQsfAxGZ1hLyDakz/TwfxKuMngACEQSN85RScaXk/cfoD7bIVuplDHG hmKVedUFVY5OIKcWHTGFGGuZmXJnlPN15+b0hD4ytgoaj8kBSeXizs1EVu5T7OfAumxk OZK6HjZmvILi1iCO2H9jqUpTFlOHzUbI5D4azbiv7kYdklLdm+Jl+jI0nM45LFjbSyBa mTALS9Wl+E47Km7cUDyuOHEjf3alfCZrDbdKCkYIsfPGCopKDcx1k81YmiLQ2qXalYiR LArDTFtCzP3n44Uedp4b29jnTdt988veqk1FBDcECVPic5LGh1oAibWt4eQd8G5ASqxH 5mUw== X-Gm-Message-State: AIkVDXIzQA4oY6EnIu9FHirLOstf4n6sDrEgpczf357aSvMpHVSCxUxPprLZCZ6rMSfiDhQE/itjcIbEiiZiAQ== X-Received: by 10.28.93.138 with SMTP id r132mr26923844wmb.17.1485423202039; Thu, 26 Jan 2017 01:33:22 -0800 (PST) MIME-Version: 1.0 Received: by 10.194.87.225 with HTTP; Thu, 26 Jan 2017 01:33:21 -0800 (PST) In-Reply-To: References: <1485363042746-5738035.post@n5.nabble.com> <5888FA6E.30204@gmx.org> From: Guillaume Laforge Date: Thu, 26 Jan 2017 10:33:21 +0100 Message-ID: Subject: =?UTF-8?B?UmU6IOetlOWkjTogQWJvdXQgdGhlICJpbXBsaWVzIiBvcGVyYXRvcihHUk9PVlktMjU3Ng==?= =?UTF-8?B?KQ==?= To: dev@groovy.apache.org Cc: Groovy_Developers Content-Type: multipart/alternative; boundary=001a1145b4744c7f330546fc0a69 archived-at: Thu, 26 Jan 2017 09:33:34 -0000 --001a1145b4744c7f330546fc0a69 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I'm not super convinced either, and I'm wondering when I'd really use such an operator. I'm kinda +0 as C=C3=A9dric here. Not that we should copy or not other languages, but are there others that have such an operator, and if this is the case, do we know how (much) it's used? On Thu, Jan 26, 2017 at 10:22 AM, C=C3=A9dric Champeau wrote: > I know it's well known in mathematical logic, but I don't want Groovy to > become Scalaz either. The route is dangerous. > > 2017-01-26 10:18 GMT+01:00 Daniel Sun : > >> Hi C=C3=A9dric, >> >> >> >> Here is the background of the =E2=80=9Cimplies=E2=80=9D operator, w= hich is well >> known in the mathematical logic =F0=9F=98=89 >> >> http://mathworld.wolfram.com/Implies.html >> >> >> >> >> >> *=E5=8F=91=E4=BB=B6=E4=BA=BA: *[hidden email] >> >> *=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: *2017=E5=B9=B41=E6=9C=8826=E6=97= =A5 17:12 >> *=E6=94=B6=E4=BB=B6=E4=BA=BA: *[hidden email] >> >> *=E4=B8=BB=E9=A2=98: *Re: About the "implies" operator(GROOVY-2576) >> >> >> I'm not convinced we should add more operators. Honestly, I had to read >> the description of the "implies" operator to understand what it does. Th= is >> is clearly not the case for || or &&, which are "well known" operators. >> >> I am also worried about code becoming ascii art: >> >> { a -> a =3D> a <=3D c =3D> d } >> >> So I'm just +0, I don't see that I would use it often enough to mitigate >> the drawbacks. >> >> 2017-01-26 1:47 GMT+01:00 Daniel Sun <[hidden email] >> >: >> Hi Jochen, >> >> Thanks for your analysis in detail :) >> >> =3D> is a very expressive operator. if we could implement it as >> +(corresponding to plus method) does and apply different business logic >> when necessary, it would be much more useful. And the default >> implementation of "implies" method can be "!a||b". >> >> As to the association of the operator, I prefer the left >> association, i.e. a =3D> b =3D> c is equivalent to (a =3D> b) =3D> c. >> >> The above is the initial plan to implement the "implies" operato= r. >> >> Cheers, >> Daniel.Sun >> >> >> =E5=9C=A8 2017=E5=B9=B41=E6=9C=8826=E6=97=A5 =E4=B8=8A=E5=8D=883:20=EF= =BC=8C"Jochen Theodorou [via Groovy]" >> > On 25.01.2017 17:50, Daniel Sun wrote: >> >> > Hi all, >> > >> > The "implies" operator "=3D>" was suggested many years ago, her= e >> is the >> > replated JIRA issue( GROOVY-2576 >> > ) . >> > >> > Do you want it for Groovy 3? (+1: yes; -1: no; 0: not bad) >> > >> > BTW, recently I have been going through the issues related to >> the old >> > parser, many issues existing for many years do not exist in the new >> parser >> > Parrot :) >> >> If we do this (and I say +1) we should clear some things: >> 1) what does a=3D>b=3D>c mean, since (a=3D>b)=3D>c is not the same as a= =3D>(b=3D>c) >> 2) use groovy truth and when to apply it? If we map a=3D>b to !a||b, the= n >> it will use Groovy truth on a and b, but if we map to an implies method >> it will get a and b, use groovy truth on them or not and we then maybe >> use groovy truth on the result. I personally would be for not using >> groovy truth here, thus make it more in line with | and &. >> 3) if a=3D>b is mapped to !a||b we will evaluate a, negate it, and >> depending on the result maybe never evaluate b. As long as a and b are >> free of side effects, that does not play an extremely important role, >> but if we map it to a method a and b will be evaluated always. If we >> would say it is more like !a|b, which would also require both being >> evaluated, then there is still the fact that !a ensures we call here >> always the boolean or function, never one defined by an arbitrary a >> 4) instead of using !a, which converts a to a boolean and negates it, we >> can also use ~a, which is a binary negate also working on booleans, but >> not converting a to a boolean if it is no boolean. Here we have to >> especially think about ~a|b calling "or" on a Pattern if a is a String. >> Also not many things besides boolean and numbers really support >> something useful of the binary negate. >> >> I mention those points so we can make a proper specification for the >> behaviour of this operator ;) >> >> bye Jochen >> >> >> ------------------------------ >> If you reply to this email, your message will be added to the discussion >> below: >> http://groovy.329449.n5.nabble.com/About-the-implies-operato >> r-GROOVY-2576-tp5738035p5738042.html >> To unsubscribe from About the "implies" operator(GROOVY-2576), click her= e >> . >> NAML >> >> >> ------------------------------ >> View this message in context: Re: About the "implies" >> operator(GROOVY-2576) >> >> >> Sent from the Groovy Dev mailing list archive >> at >> Nabble.com. >> >> >> >> ------------------------------ >> If you reply to this email, your message will be added to the discussion >> below: >> http://groovy.329449.n5.nabble.com/About-the-implies-operato >> r-GROOVY-2576-tp5738035p5738104.html >> To unsubscribe from About the "implies" operator(GROOVY-2576), click her= e >> . >> NAML >> >> >> ------------------------------ >> View this message in context: =E7=AD=94=E5=A4=8D: About the "implies" >> operator(GROOVY-2576) >> >> >> Sent from the Groovy Dev mailing list archive >> at >> Nabble.com. >> > > --=20 Guillaume Laforge Apache Groovy committer & PMC Vice-President Developer Advocate @ Google Cloud Platform Blog: http://glaforge.appspot.com/ Social: @glaforge / Google+ --001a1145b4744c7f330546fc0a69 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I'm not super convinced either, and I'm wondering = when I'd really use such an operator.
I'm kinda +0 as C=C3=A9dr= ic here.

Not that we should copy or not other lang= uages, but are there others that have such an operator, and if this is the = case, do we know how (much) it's used?

On Thu, Jan 26, 2017 at 10:22 AM, C=C3= =A9dric Champeau <cedric.champeau@gmail.com> wrote:<= br>
I know it's well kno= wn in mathematical logic, but I don't want Groovy to become Scalaz eith= er. The route is dangerous.

2017-01-26 10:18 GM= T+01:00 Daniel Sun <realbluesun@hotmail.com>:

Hi C=C3=A9dric,

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0 Here i= s the background of the =E2=80=9Cimplies=E2=80=9D operator, which is well known in the mathemat= ical logic =F0=9F=98=89

<= /u>

http://mathworld.wolfram.com/Implies.html

=C2=A0

=C2=A0

=E5=8F=91=E4=BB= =B6=E4=BA=BA: [hidden email]
=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2017=E5=B9=B41= =E6=9C=8826=E6=97=A5 17:12=
=E6=94=B6=E4=BB=B6=E4=BA=BA: = [hidden email]
=E4=B8=BB=E9=A2=98: Re: About the "implies" operator(GROOVY-2576)

=C2=A0

I'm not convinced we should add more operators. Honest= ly, I had to read the description of the "implies" operator to un= derstand what it does. This is clearly not the case for || or &&, w= hich are "well known" operators.

I am also worried about code becoming ascii art:

{ a -> a =3D> a <=3D c =3D> d }

So I'm just +0, I don't see that I would use it often enough t= o mitigate the drawbacks.

2017-01-26 1:47 GMT+01:00 Daniel Sun <[hid= den email]>:
Hi Jochen,

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Thanks for your analysis in= detail :)

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =3D> is a very exp= ressive operator. if we could implement it as +(corresponding to plus metho= d) does and apply different business logic when necessary, it would be much= more useful. And the default implementation of "implies" method = can be "!a||b".

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 As to the assoc= iation of the operator, I prefer the left association, i.e. a =3D> b =3D= > c is equivalent to (a =3D> b) =3D> c.

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The above is the init= ial plan to implement the=C2=A0 "implies" operator.

Cheers,
Daniel.Sun


=E5=9C=A8 2017=E5=B9=B41=E6=9C=8826=E6=97=A5 =E4=B8=8A=E5= =8D=883:20=EF=BC=8C"Jochen Theodorou [via Groovy]" <ml-node+s3= 29449n5738042h6
On 25.01.2017 1= 7:50, Daniel Sun wrote:

> Hi all,
>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0The "implies" operator "=3D&= gt;" was suggested many years ago, here is the
> replated JIRA issue( GROOVY-2576
> <https://issues.apache.org= /jira/browse/GROOVY-2576> =C2=A0) .
>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0Do you want it for Groovy 3? (+1: yes; -1: = no; 0: not bad)
>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0BTW, recently I have been going through the= issues related to the old
> parser, many issues existing for many years do not exist in the new pa= rser
> Parrot :)

If we do this (and I say +1) we should clear some things:
1) what does a=3D>b=3D>c mean, since (a=3D>b)=3D>c is not the s= ame as a=3D>(b=3D>c)
2) use groovy truth and when to apply it? If we map a=3D>b to !a||b, the= n
it will use Groovy truth on a and b, but if we map to an implies method it will get a and b, use groovy truth on them or not and we then maybe
use groovy truth on the result. I personally would be for not using
groovy truth here, thus make it more in line with | and &.
3) if a=3D>b is mapped to !a||b we will evaluate a, negate it, and
depending on the result maybe never evaluate b. As long as a and b are
free of side effects, that does not play an extremely important role,
but if we map it to a method a and b will be evaluated always. If we
would say it is more like !a|b, which would also require both being
evaluated, then there is still the fact that !a ensures we call here
always the boolean or function, never one defined by an arbitrary a
4) instead of using !a, which converts a to a boolean and negates it, we can also use ~a, which is a binary negate also working on booleans, but not converting a to a boolean if it is no boolean. Here we have to
especially think about ~a|b calling "or" on a Pattern if a is a S= tring.
Also not many things besides boolean and numbers really support
something useful of the binary negate.

I mention those points so we can make a proper specification for the
behaviour of this operator ;)

bye Jochen


If you reply to this email, your message wi= ll be added to the discussion below:
http://groovy.329449.n5.nabble.com/About-the-implies-opera= tor-GROOVY-2576-tp5738035p5738042.html
To unsubscribe from About the "implies" operator(GROOVY-2576), click here.
NAML

View this message in context: Re: About the "implies" operator(GROOVY-2576)

Sent from the Groovy Dev mailing list archive at Nabble.com.



If you reply to this email, your message wi= ll be added to the discussion below:
http://groovy.329449.n5.nabble.com/About-the-i= mplies-operator-GROOVY-2576-tp5738035p5738104.html
To unsubscribe from About the "implies" operator(GROOVY-2576), click here.
NAML
=09 =09 =09
View this message in context: =E7=AD=94=E5=A4=8D: About the "implies" operator(GROOVY-25= 76)

Sent from the Groovy Dev mailing list archive at Nabble.c= om.




--
=
=
Guillaume Laforge
Apache Groovy commit= ter & PMC Vice-President
Developer Advocate @ Goo= gle Cloud Platform

Blog:=C2=A0http://glaforge.appspot.com/
<= div>Social: @glaf= orge=C2=A0/ Google+
<= /div>
--001a1145b4744c7f330546fc0a69--