groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Remi Forax <fo...@univ-mlv.fr>
Subject Re: 答复: About the "implies" operator(GROOVY-2576)
Date Thu, 26 Jan 2017 10:05:44 GMT
The other problem i see is that the fat arrow => is used by several mainstream languages
; C#, Scala, JavaScript at least ; for declaring a lambda. 
This will confuse people in my opinion. 

Moreover as Jochen said , implies is a lazy operator, like && and ||, so the operator
should be more =>=> than => (i.e !a || b vs !a | b). 
Also if there is a method 'implies' as there is a method 'plus', implies should take a closure
and not the result of an expression. 
At that point, the question is whenever or not to also implement && and || as method
and has a general 'lift' syntax when declaring a method, it will make simple macro far easier
to write at the expense of more magic. 

Rémi 

> De: "Guillaume Laforge" <glaforge@gmail.com>
> À: dev@groovy.apache.org
> Cc: "Groovy_Developers" <dev@groovy.incubator.apache.org>
> Envoyé: Jeudi 26 Janvier 2017 10:33:21
> Objet: Re: 答复: About the "implies" operator(GROOVY-2576)

> I'm not super convinced either, and I'm wondering when I'd really use such an
> operator.
> I'm kinda +0 as Cédric 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édric Champeau < cedric.champeau@gmail.com >
> 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 < realbluesun@hotmail.com > :

>>> Hi Cédric,

>>> Here is the background of the “implies” operator, which is well known in
the
>>> mathematical logic 😉

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

>>> 发件人 : [hidden email]
>>> 发送时间 : 2017 年 1 月 26 日 17:12
>>> 收件人 : [hidden email]
>>> 主题 : 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. This is
>>> clearly not the case for || or &&, which are "well known" operators.

>>> I am also worried about code becoming ascii art:

>>> { a -> a => a <= c => 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 :)

>>> => 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
=>
>>> b => c is equivalent to (a => b) => c.

>>> The above is the initial plan to implement the "implies" operator.

>>> Cheers,
>>> Daniel.Sun

>>> 在 2017年1月26日 上午3:20,"Jochen Theodorou [via Groovy]" <ml-node+s329449n5738042h6
>>> On 25.01.2017 17:50, Daniel Sun wrote:

>>> > Hi all,

>>> > The "implies" operator "=>" was suggested many years ago, here is the
>>> > replated JIRA issue( GROOVY-2576
>>> > < https://issues.apache.org/jira/browse/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=>b=>c mean, since (a=>b)=>c is not the same as a=>(b=>c)
>>> 2) use groovy truth and when to apply it? If we map a=>b to !a||b, then
>>> 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=>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-operator-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 will be added to the discussion below:
>>> http://groovy.329449.n5.nabble.com/About-the-implies-operator-GROOVY-2576-tp5738035p5738104.html
>>> To unsubscribe from About the "implies" operator(GROOVY-2576), click here .
>>> NAML

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

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

> --
> Guillaume Laforge
> Apache Groovy committer & PMC Vice-President
> Developer Advocate @ Google Cloud Platform

> Blog: http://glaforge.appspot.com/
> Social: @glaforge / Google+

Mime
View raw message