groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andres Almiray <aalmi...@gmail.com>
Subject Re: 答复: About the "implies" operator(GROOVY-2576)
Date Thu, 26 Jan 2017 10:13:49 GMT
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 <forax@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" <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]
>>> <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-
>>> operator-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-
>>> operator-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>
>
>

Mime
View raw message