groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Dawson <david.daw...@simplicityitself.com>
Subject Re: 答复: About the "implies" operator(GROOVY-2576)
Date Thu, 26 Jan 2017 10:24:04 GMT
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 <aalmiray@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 <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-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.dawson@simplicityitself.com
http://www.simplicityitself.com

Mime
View raw message