You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@groovy.apache.org by Daniel Sun <re...@hotmail.com> on 2017/01/25 16:50:42 UTC
About the "implies" operator(GROOVY-2576)
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 :)
Cheers,
Daniel.Sun
--
View this message in context: http://groovy.329449.n5.nabble.com/About-the-implies-operator-GROOVY-2576-tp5738035.html
Sent from the Groovy Dev mailing list archive at Nabble.com.
Re: 答复: About the "implies" operator(GROOVY-2576)
Posted by Jochen Theodorou <bl...@gmx.org>.
On 26.01.2017 11:05, Remi Forax wrote:
[...]
> 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).
I tried to say that if we see it as !a || b, we have a lazy operator and
if we map it to a method call, then we cannot have this. The big
difference is that || is a built-in operator working on booleans,
nothing else. To ensure a and b are booleans we are using Groovy Truth
on them. a|b is mapped to a method, thus a and b will have eager
evaluation. If Groovy Truth is applied to them or not depends on the
methods implementation.
If you now have Java-code in the form of let's say
foo!=null && bar.x
then you can rewrite it to foo!=null => !bar.x, then you would get a
NPE, if you mapped it to a implies method, that takes foo!=null and !bar.x.
> 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.
I think that would have quite the negative impact on performance for ||.
At least if the operands are booleans
bye Jochen
Re: 答复: About the "implies" operator(GROOVY-2576)
Posted by Sergei Egorov <bs...@gmail.com>.
-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 <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" <gl...@gmail.com>
> *À: *dev@groovy.apache.org
> *Cc: *"Groovy_Developers" <de...@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 <re...@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>
>
>
答复: About the "implies" operator(GROOVY-2576)
Posted by Daniel Sun <re...@hotmail.com>.
Hi Jesper,
As to the custom operator, I have an experimental branch to play with it(https://github.com/danielsun1106/groovy-parser/tree/customOperator) 😉
If I’ve caught Jochen’s words, he wants a general approach to extend a grammar(not only operator). As far as I know, no approach can deal with it.
Thanks for your suggestion 😊
Cheers,
Daniel.Sun
发件人: Jesper Steen Møller [via Groovy]<ma...@n5.nabble.com>
发送时间: 2017年1月26日 19:24
收件人: Daniel Sun<ma...@hotmail.com>
主题: Re: About the "implies" operator(GROOVY-2576)
Hi Jochen and Daniel
Not entirely correct: There are some ways to extend a grammar with new opperators, as demonstrated in http://stackoverflow.com/questions/29894457/dynamic-operator-tokens-in-antlr4
However, this still needs to happen before lexing and parsing, so you can't "fix" it with an AST transformer.
-Jesper
On 26 Jan 2017, at 12.20, Daniel Sun <[hidden email]</user/SendEmail.jtp?type=node&node=5738122&i=0>> wrote:
Hi Jochen,
We can enable or disable some rules in the antlr4 grammar, but no rules can be defined and enabled on the fly… as you know, the parser is generated by antlr4.
Cheers,
Daniel.Sun
发件人: <a href="x-msg://28/user/SendEmail.jtp?type=node&node=5738120&i=0" target="_top" rel="nofollow" link="external" class="">[hidden email]
发送时间: 2017年1月26日 19:07
收件人: <a href="x-msg://28/user/SendEmail.jtp?type=node&node=5738120&i=1" target="_top" rel="nofollow" link="external" class="">[hidden email]
主题: Re: 答复: About the "implies" operator(GROOVY-2576)
On 26.01.2017 11:13, Andres Almiray wrote:
> Here's another idea:
>
> What if this new operator and other syntax changes were to be introduced
> as parser/compiler plugins?
compiler itself, sure we can do something here... but for the parser?
Daniel, is it possible? I would be surprised if it is, but you never know ;)
> 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.
I have my doubts, since the parser is generated from a grammar
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-tp5738035p5738119.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-tp5738035p5738120.html>
Sent from the Groovy Dev mailing list archive<http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html> at Nabble.com<http://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-tp5738035p5738122.html
To unsubscribe from About the "implies" operator(GROOVY-2576), click here<http://groovy.329449.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=5738035&code=cmVhbGJsdWVzdW5AaG90bWFpbC5jb218NTczODAzNXwxMTQ2MjE4MjI1>.
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: http://groovy.329449.n5.nabble.com/About-the-implies-operator-GROOVY-2576-tp5738035p5738123.html
Sent from the Groovy Dev mailing list archive at Nabble.com.
Re: About the "implies" operator(GROOVY-2576)
Posted by Jochen Theodorou <bl...@gmx.org>.
On 26.01.2017 12:23, Jesper Steen M�ller wrote:
> Hi Jochen and Daniel
>
> Not entirely correct: There are some ways to extend a grammar with new
> opperators, as demonstrated
> in http://stackoverflow.com/questions/29894457/dynamic-operator-tokens-in-antlr4
> However, this still needs to happen before lexing and parsing, so you
> can't "fix" it with an AST transformer.
before lexing is fine, if the lexer had a dynamic way of adding and
replacing grammar rules. Because the usage you want to have is the base
lexer and some kind of plugin which is not a new full antlr4 generated
parser/lexer. On the other hand, maybe that would be better, since the
grammar rules will easily get in conflict with each other
bye Jochen
Re: About the "implies" operator(GROOVY-2576)
Posted by Jesper Steen Møller <je...@selskabet.org>.
Hi Jochen and Daniel
Not entirely correct: There are some ways to extend a grammar with new opperators, as demonstrated in http://stackoverflow.com/questions/29894457/dynamic-operator-tokens-in-antlr4 <http://stackoverflow.com/questions/29894457/dynamic-operator-tokens-in-antlr4>
However, this still needs to happen before lexing and parsing, so you can't "fix" it with an AST transformer.
-Jesper
> On 26 Jan 2017, at 12.20, Daniel Sun <re...@hotmail.com> wrote:
>
> Hi Jochen,
>
>
>
> We can enable or disable some rules in the antlr4 grammar, but no rules can be defined and enabled on the fly… as you know, the parser is generated by antlr4.
>
>
>
> Cheers,
>
> Daniel.Sun
>
>
>
> 发件人: [hidden email] <x-msg://28/user/SendEmail.jtp?type=node&node=5738120&i=0>
> 发送时间: 2017年1月26日 19:07
> 收件人: [hidden email] <x-msg://28/user/SendEmail.jtp?type=node&node=5738120&i=1>
> 主题: Re: 答复: About the "implies" operator(GROOVY-2576)
>
>
>
>
>
> On 26.01.2017 11:13, Andres Almiray wrote:
> > Here's another idea:
> >
> > What if this new operator and other syntax changes were to be introduced
> > as parser/compiler plugins?
>
> compiler itself, sure we can do something here... but for the parser?
> Daniel, is it possible? I would be surprised if it is, but you never know ;)
>
> > 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.
>
> I have my doubts, since the parser is generated from a grammar
>
> 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-tp5738035p5738119.html <http://groovy.329449.n5.nabble.com/About-the-implies-operator-GROOVY-2576-tp5738035p5738119.html>
> To unsubscribe from About the "implies" operator(GROOVY-2576), click here <applewebdata://77214BBB-C69F-41EE-8751-D8A0B2937D8D>.
> 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-tp5738035p5738120.html>
> Sent from the Groovy Dev mailing list archive <http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html> at Nabble.com.
答复: 答复: About the "implies" operator(GROOVY-2576)
Posted by Daniel Sun <re...@hotmail.com>.
Hi Jochen,
We can enable or disable some rules in the antlr4 grammar, but no rules can be defined and enabled on the fly… as you know, the parser is generated by antlr4.
Cheers,
Daniel.Sun
发件人: Jochen Theodorou [via Groovy]<ma...@n5.nabble.com>
发送时间: 2017年1月26日 19:07
收件人: Daniel Sun<ma...@hotmail.com>
主题: Re: 答复: About the "implies" operator(GROOVY-2576)
On 26.01.2017 11:13, Andres Almiray wrote:
> Here's another idea:
>
> What if this new operator and other syntax changes were to be introduced
> as parser/compiler plugins?
compiler itself, sure we can do something here... but for the parser?
Daniel, is it possible? I would be surprised if it is, but you never know ;)
> 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.
I have my doubts, since the parser is generated from a grammar
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-tp5738035p5738119.html
To unsubscribe from About the "implies" operator(GROOVY-2576), click here<http://groovy.329449.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=5738035&code=cmVhbGJsdWVzdW5AaG90bWFpbC5jb218NTczODAzNXwxMTQ2MjE4MjI1>.
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: http://groovy.329449.n5.nabble.com/About-the-implies-operator-GROOVY-2576-tp5738035p5738120.html
Sent from the Groovy Dev mailing list archive at Nabble.com.
Re: 答复: About the "implies" operator(GROOVY-2576)
Posted by Jochen Theodorou <bl...@gmx.org>.
On 26.01.2017 11:13, Andres Almiray wrote:
> Here's another idea:
>
> What if this new operator and other syntax changes were to be introduced
> as parser/compiler plugins?
compiler itself, sure we can do something here... but for the parser?
Daniel, is it possible? I would be surprised if it is, but you never know ;)
> 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.
I have my doubts, since the parser is generated from a grammar
bye Jochen
Re: 答复: About the "implies" operator(GROOVY-2576)
Posted by David Dawson <da...@simplicityitself.com>.
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 <aa...@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" <gl...@gmail.com>
>> *À: *dev@groovy.apache.org
>> *Cc: *"Groovy_Developers" <de...@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 <re...@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
Re: 答复: About the "implies" operator(GROOVY-2576)
Posted by Andres Almiray <aa...@gmail.com>.
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" <gl...@gmail.com>
> *À: *dev@groovy.apache.org
> *Cc: *"Groovy_Developers" <de...@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 <re...@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>
>
>
Re: 答复: About the "implies" operator(GROOVY-2576)
Posted by Remi Forax <fo...@univ-mlv.fr>.
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" <gl...@gmail.com>
> À: dev@groovy.apache.org
> Cc: "Groovy_Developers" <de...@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+
Re: 答复: 答复: About the "implies" operator(GROOVY-2576)
Posted by Jochen Theodorou <bl...@gmx.org>.
On 26.01.2017 12:04, C�dric Champeau wrote:
> So I used IntelliJ's awesome structural search to find this pattern in
> the Gradle codebase:
>
> !$a$ || $b$
>
> It returns 41 matches, for a total of 49807 source files. FWIW
!a||b becomes a=>b
a||b becomes !a=>b
a||!b becomes !a=>!b
!a||!b becomes a=>!b
And since !a||b is the same as a&&!b
a&&b becomes a=>!b
a&&!b becomes a=>b
!a&&b becomes !a=>!b
!a&&!b becomes !a=>b
In Closure.java we have for example this condition: (secondTry!=null &&
firstTry!=this && firstTry!=secondTry
we could write that for example as
secondTry==null => (firstTry==this || firstTry==secondTry)
(secondTry!=null && firstTry!=this) => firstTry==secondTry
secondTry!=null => firstTry==this => firstTry==secondTry
bye Jochen
Re: 答复: 答复: About the "implies" operator(GROOVY-2576)
Posted by Cédric Champeau <ce...@gmail.com>.
So I used IntelliJ's awesome structural search to find this pattern in the
Gradle codebase:
!$a$ || $b$
It returns 41 matches, for a total of 49807 source files. FWIW
2017-01-26 11:53 GMT+01:00 Daniel Sun <re...@hotmail.com>:
> Hi Jochen,
>
>
>
> Some like it, some don’t. Understanding the new operator needs some
> knowledge of mathematical logic.
>
>
>
> Cheers,
>
> Daniel.Sun
>
>
>
> *发件人: *[hidden email]
> <http:///user/SendEmail.jtp?type=node&node=5738116&i=0>
> *发送时间: *2017年1月26日 18:44
> *收件人: *[hidden email]
> <http:///user/SendEmail.jtp?type=node&node=5738116&i=1>
> *主题: *Re: 答复: About the "implies" operator(GROOVY-2576)
>
>
>
>
> On 26.01.2017 10:33, Guillaume Laforge wrote:
> > I'm not super convinced either, and I'm wondering when I'd really use
> > such an operator.
>
> I would and there would have been cases in MetaClassImpl where I would
> have used it already, if Java would be able to do such things.
>
> 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-
> tp5738035p5738114.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-tp5738035p5738116.html>
>
> Sent from the Groovy Dev mailing list archive
> <http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html> at
> Nabble.com.
>
答复: 答复: About the "implies" operator(GROOVY-2576)
Posted by Daniel Sun <re...@hotmail.com>.
Hi Jochen,
Some like it, some don’t. Understanding the new operator needs some knowledge of mathematical logic.
Cheers,
Daniel.Sun
发件人: Jochen Theodorou [via Groovy]<ma...@n5.nabble.com>
发送时间: 2017年1月26日 18:44
收件人: Daniel Sun<ma...@hotmail.com>
主题: Re: 答复: About the "implies" operator(GROOVY-2576)
On 26.01.2017 10:33, Guillaume Laforge wrote:
> I'm not super convinced either, and I'm wondering when I'd really use
> such an operator.
I would and there would have been cases in MetaClassImpl where I would
have used it already, if Java would be able to do such things.
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-tp5738035p5738114.html
To unsubscribe from About the "implies" operator(GROOVY-2576), click here<http://groovy.329449.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=5738035&code=cmVhbGJsdWVzdW5AaG90bWFpbC5jb218NTczODAzNXwxMTQ2MjE4MjI1>.
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: http://groovy.329449.n5.nabble.com/About-the-implies-operator-GROOVY-2576-tp5738035p5738116.html
Sent from the Groovy Dev mailing list archive at Nabble.com.
Re: 答复: About the "implies" operator(GROOVY-2576)
Posted by Jochen Theodorou <bl...@gmx.org>.
On 26.01.2017 10:33, Guillaume Laforge wrote:
> I'm not super convinced either, and I'm wondering when I'd really use
> such an operator.
I would and there would have been cases in MetaClassImpl where I would
have used it already, if Java would be able to do such things.
bye Jochen
答复: 答复: About the "implies" operator(GROOVY-2576)
Posted by Daniel Sun <re...@hotmail.com>.
Hi Guillaume,
When we deal with logic, abstraction is very important to simplify reasoning. The “implies” operator can give us a hand here 😊
Cheers,
Daniel.Sun
发件人: Guillaume Laforge [via Groovy]<ma...@n5.nabble.com>
发送时间: 2017年1月26日 17:34
收件人: Daniel Sun<ma...@hotmail.com>
主题: 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 <[hidden email]</user/SendEmail.jtp?type=node&node=5738107&i=0>> 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 <[hidden email]</user/SendEmail.jtp?type=node&node=5738107&i=1>>:
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>
________________________________
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-tp5738035p5738107.html
To unsubscribe from About the "implies" operator(GROOVY-2576), click here<http://groovy.329449.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=5738035&code=cmVhbGJsdWVzdW5AaG90bWFpbC5jb218NTczODAzNXwxMTQ2MjE4MjI1>.
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: http://groovy.329449.n5.nabble.com/About-the-implies-operator-GROOVY-2576-tp5738035p5738108.html
Sent from the Groovy Dev mailing list archive at Nabble.com.
Re: 答复: About the "implies" operator(GROOVY-2576)
Posted by Guillaume Laforge <gl...@gmail.com>.
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 <re...@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>
Re: 答复: About the "implies" operator(GROOVY-2576)
Posted by Cédric Champeau <ce...@gmail.com>.
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 <re...@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-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.
>
答复: About the "implies" operator(GROOVY-2576)
Posted by Daniel Sun <re...@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
发件人: Cédric Champeau [via Groovy]<ma...@n5.nabble.com>
发送时间: 2017年1月26日 17:12
收件人: Daniel Sun<ma...@hotmail.com>
主题: 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]</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<http://groovy.329449.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=5738035&code=cmVhbGJsdWVzdW5AaG90bWFpbC5jb218NTczODAzNXwxMTQ2MjE4MjI1>.
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: http://groovy.329449.n5.nabble.com/About-the-implies-operator-GROOVY-2576-tp5738035p5738105.html
Sent from the Groovy Dev mailing list archive at Nabble.com.
Re: About the "implies" operator(GROOVY-2576)
Posted by Cédric Champeau <ce...@gmail.com>.
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 <re...@hotmail.com>:
> 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.
>
Re: About the "implies" operator(GROOVY-2576)
Posted by Daniel Sun <re...@hotmail.com>.
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<http://groovy.329449.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=5738035&code=cmVhbGJsdWVzdW5AaG90bWFpbC5jb218NTczODAzNXwxMTQ2MjE4MjI1>.
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: http://groovy.329449.n5.nabble.com/About-the-implies-operator-GROOVY-2576-tp5738035p5738043.html
Sent from the Groovy Dev mailing list archive at Nabble.com.
Re: About the "implies" operator(GROOVY-2576)
Posted by Jochen Theodorou <bl...@gmx.org>.
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
Re: About the "implies" operator(GROOVY-2576)
Posted by Marc Hadfield <ma...@hadfield.org>.
+1 yes, especially if it's overloadable as per the other operators
On Wed, Jan 25, 2017 at 11:50 AM, Daniel Sun <re...@hotmail.com>
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 :)
>
> Cheers,
> Daniel.Sun
>
>
>
> --
> View this message in context: http://groovy.329449.n5.
> nabble.com/About-the-implies-operator-GROOVY-2576-tp5738035.html
> Sent from the Groovy Dev mailing list archive at Nabble.com.
>
Re: About the "implies" operator(GROOVY-2576)
Posted by Roman Shaposhnik <ro...@shaposhnik.org>.
+1
On Wed, Jan 25, 2017 at 9:28 AM, Mario Garcia <ma...@gmail.com> wrote:
> +1 if follows the convention mentioned by Andres
>
> On 25 Jan 2017 17:58, "Andres Almiray" <aa...@gmail.com> wrote:
>>
>> Is the "implies" method supposed to work with Groovy Truth or with
>> booleans only?
>> If the former then this would pose a problem as anyone that has defined an
>> "X implies(Y)" method would have access to =>
>> If the latter then I guess that may not be a proplem.
>>
>> Assuming "X implies(Y)" would be the convention for => just like "X
>> plus(Y)" is for +, and so on.
>>
>> 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 Wed, Jan 25, 2017 at 5:50 PM, Daniel Sun <re...@hotmail.com>
>> 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 :)
>>>
>>> Cheers,
>>> Daniel.Sun
>>>
>>>
>>>
>>> --
>>> View this message in context:
>>> http://groovy.329449.n5.nabble.com/About-the-implies-operator-GROOVY-2576-tp5738035.html
>>> Sent from the Groovy Dev mailing list archive at Nabble.com.
>>
>>
>
Re: About the "implies" operator(GROOVY-2576)
Posted by Mario Garcia <ma...@gmail.com>.
+1 if follows the convention mentioned by Andres
On 25 Jan 2017 17:58, "Andres Almiray" <aa...@gmail.com> wrote:
> Is the "implies" method supposed to work with Groovy Truth or with
> booleans only?
> If the former then this would pose a problem as anyone that has defined an
> "X implies(Y)" method would have access to =>
> If the latter then I guess that may not be a proplem.
>
> Assuming "X implies(Y)" would be the convention for => just like "X
> plus(Y)" is for +, and so on.
>
> 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 Wed, Jan 25, 2017 at 5:50 PM, Daniel Sun <re...@hotmail.com>
> 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 :)
>>
>> Cheers,
>> Daniel.Sun
>>
>>
>>
>> --
>> View this message in context: http://groovy.329449.n5.nabble
>> .com/About-the-implies-operator-GROOVY-2576-tp5738035.html
>> Sent from the Groovy Dev mailing list archive at Nabble.com.
>>
>
>
Re: About the "implies" operator(GROOVY-2576)
Posted by Andres Almiray <aa...@gmail.com>.
Is the "implies" method supposed to work with Groovy Truth or with booleans
only?
If the former then this would pose a problem as anyone that has defined an
"X implies(Y)" method would have access to =>
If the latter then I guess that may not be a proplem.
Assuming "X implies(Y)" would be the convention for => just like "X
plus(Y)" is for +, and so on.
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 Wed, Jan 25, 2017 at 5:50 PM, Daniel Sun <re...@hotmail.com> 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 :)
>
> Cheers,
> Daniel.Sun
>
>
>
> --
> View this message in context: http://groovy.329449.n5.
> nabble.com/About-the-implies-operator-GROOVY-2576-tp5738035.html
> Sent from the Groovy Dev mailing list archive at Nabble.com.
>