For me, what is lovely about Groovy is not how much is has "in the box", it's the flexibility and extensibility of the language.
I don't think I would use this operator, its confusing for me (even the unpacked version I would probably rewrite), and so would be confusing for junior devs, which I see as dangerous. Having the option of changing some base syntax though would be a huge boon for dsl writers, one of the big niches that Groovy dominates in the jvm world. I would certainly appreciate and use that. Groovy 3 couldn't come fast enough for me if it had that in. David. On 26 January 2017 at 10:13, Andres Almiray <aalmi...@gmail.com> wrote: > Here's another idea: > > What if this new operator and other syntax changes were to be introduced > as parser/compiler plugins? > > This way the core syntax stays the same yet it may open the possibility > for certain groups to enhance the Groovy syntax according to their needs > without affecting everyone else. > > Don't how how feasible this is given that it requires changes to both > parser and compiler APIs. > > Cheers, > Andres > > ------------------------------------------- > Java Champion; Groovy Enthusiast > http://jroller.com/aalmiray > http://www.linkedin.com/in/aalmiray > -- > What goes up, must come down. Ask any system administrator. > There are 10 types of people in the world: Those who understand binary, > and those who don't. > To understand recursion, we must first understand recursion. > > On Thu, Jan 26, 2017 at 11:05 AM, Remi Forax <fo...@univ-mlv.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" <glafo...@gmail.com> >> *À: *dev@groovy.apache.org >> *Cc: *"Groovy_Developers" <d...@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.champ...@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 <realblue...@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(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] >>>> <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 "!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-operato >>>> r-GROOVY-2576-tp5738035p5738042.html >>>> To unsubscribe from About the "implies" operator(GROOVY-2576), 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: Re: About the "implies" >>>> operator(GROOVY-2576) >>>> <http://groovy.329449.n5.nabble.com/About-the-implies-operator-GROOVY-2576-tp5738035p5738043.html> >>>> >>>> Sent from the Groovy Dev mailing list archive >>>> <http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.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/About-the-implies-operato >>>> r-GROOVY-2576-tp5738035p5738104.html >>>> To unsubscribe from About the "implies" operator(GROOVY-2576), 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: 答复: About the "implies" >>>> operator(GROOVY-2576) >>>> <http://groovy.329449.n5.nabble.com/About-the-implies-operator-GROOVY-2576-tp5738035p5738105.html> >>>> >>>> Sent from the Groovy Dev mailing list archive >>>> <http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html> at >>>> Nabble.com. >>>> >>> >>> >> >> >> -- >> Guillaume Laforge >> Apache Groovy committer & PMC Vice-President >> 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> >> >> > -- David Dawson | CEO | Simplicity Itself Tel +44 7866 011 256 Skype: davidadawson david.daw...@simplicityitself.com http://www.simplicityitself.com
