1 from me.
First of all, it's hard to understand what it does and to read it later.
Also, => is Lambda notation in JS/C# and people from these languages will
be very confused about it.
On Thu, Jan 26, 2017 at 12:06 PM Remi Forax <forax@univmlv.fr> wrote:
> 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(GROOVY2576)
>
> 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.
>
> 20170126 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]
> <http:///user/SendEmail.jtp?type=node&node=5738105&i=0>
> *发送时间: *2017年1月26日 17:12
> *收件人: *[hidden email]
> <http:///user/SendEmail.jtp?type=node&node=5738105&i=1>
> *主题: *Re: About the "implies" operator(GROOVY2576)
>
>
> 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.
>
> 20170126 1:47 GMT+01:00 Daniel Sun <[hidden email]
> <http:///user/SendEmail.jtp?type=node&node=5738104&i=0>>:
> 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 "!ab".
>
> 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]"
> <mlnode+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( GROOVY2576
> > <https://issues.apache.org/jira/browse/GROOVY2576> ) .
> >
> > 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 !ab, 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 !ab 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 !ab, 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 ~ab 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/AbouttheimpliesoperatorGROOVY2576tp5738035p5738042.html
> To unsubscribe from About the "implies" operator(GROOVY2576), 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.BasicNamespacenabble.view.web.template.NabbleNamespacenabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.namlinstant_emails%21nabble%3Aemail.namlsend_instant_email%21nabble%3Aemail.naml>
>
> 
> View this message in context: Re: About the "implies"
> operator(GROOVY2576)
> <http://groovy.329449.n5.nabble.com/AbouttheimpliesoperatorGROOVY2576tp5738035p5738043.html>
>
> Sent from the Groovy Dev mailing list archive
> <http://groovy.329449.n5.nabble.com/GroovyDevf372993.html> at
> Nabble.com.
>
>
>
> 
> If you reply to this email, your message will be added to the discussion
> below:
>
> http://groovy.329449.n5.nabble.com/AbouttheimpliesoperatorGROOVY2576tp5738035p5738104.html
> To unsubscribe from About the "implies" operator(GROOVY2576), 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.BasicNamespacenabble.view.web.template.NabbleNamespacenabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.namlinstant_emails%21nabble%3Aemail.namlsend_instant_email%21nabble%3Aemail.naml>
>
> 
> View this message in context: 答复: About the "implies"
> operator(GROOVY2576)
> <http://groovy.329449.n5.nabble.com/AbouttheimpliesoperatorGROOVY2576tp5738035p5738105.html>
>
> Sent from the Groovy Dev mailing list archive
> <http://groovy.329449.n5.nabble.com/GroovyDevf372993.html> at
> Nabble.com.
>
>
>
>
>
> 
> Guillaume Laforge
> Apache Groovy committer & PMC VicePresident
> Developer Advocate @ Google Cloud Platform
>
> Blog: http://glaforge.appspot.com/
> Social: @glaforge <http://twitter.com/glaforge> / Google+
> <https://plus.google.com/u/0/114130972232398734985/posts>
>
>
