You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@groovy.apache.org by 孙 岚 <re...@hotmail.com> on 2016/10/30 07:02:58 UTC
Custom operator for Groovy 3
Hi all,
The new parser support defining custom operator now. The initial implementation is on the customOperator branch of groovy-parser(https://github.com/danielsun1106/groovy-parser/tree/customOperator).
Some examples can be found at https://github.com/danielsun1106/groovy-parser/blob/c3259607c4ee0cda6e5619bed35d0674e26f78aa/src/test/resources/core/CustomOperator_01x.groovy
In order to make the custom operator have more priorities, the custom operators have lower priority by default, and the priority can be changed by using parentheses.
Any thoughts?
Cheers,
Daniel.Sun
Re: Custom operator for Groovy 3
Posted by "Daniel.Sun" <re...@hotmail.com>.
Hi Jochen,
Thanks for your explaining the traps of custom operator in Groovy :)
The experimental code is on the customOperator branch, which will not
be merged to master ;)
Cheers,
Daniel.Sun
--
View this message in context: http://groovy.329449.n5.nabble.com/Custom-operator-for-Groovy-3-tp5736388p5736404.html
Sent from the Groovy Dev mailing list archive at Nabble.com.
Re: Custom operator for Groovy 3
Posted by "Daniel.Sun" <re...@hotmail.com>.
Hi Jochen,
I'll set aside more time on your new idea ;)
Cheers,
Daniel.Sun
在 "Jochen Theodorou [via Groovy]" <ml...@n5.nabble.com>，2016年10月30日 下午8:16写道：
On 30.10.2016 11:07, Daniel.Sun wrote:
> Hi Paolo,
>
> There are some limitations when we use antlr to define grammar, so the
> backticks are used to distinguish with other operators.
>
> I saw an answer from Jochen(shown as follow), so I tryied to add this
> experimental feature
>
> "We always wanted the ability to define an operator through the user in
> Groovy, but so far we haven't gotten around the problems that come along
> with that."
> http://stackoverflow.com/questions/6485861/is-it-possible-to-define-a-new-operator-in-groovy/10848093#10848093
I actually gave up on custom operators for a bit.
In Scala you have a natural mapping of "a + b" to a."+"(b). But in
Groovy that would be a(+).b. That means binary expressions and command
expressions follow different patterns. That means in a+b+c we do not
naturally get (a+b)+c, we get a(+).b(+).c. This is what makes you
require special characters to distinguish operators and command
expressions in the usage of those
And if you change precedence rules like you described... a + b + c is
(a+b)+c while a + b "`x`" c would become a+(b "`x`" c) instead.
But to develop the idea... how about saying that everything between dot
and an identifier is an operator? So a .x c would be a.x(c).. well that
looks obvious, but a .>? c becomes a.">?"(c). This kind of logic would
reduce the need for special characters and be in line with existing
syntax. And at the same time precedence rule would be clear. a + b .>? c
would be a+(b.">?"(c)) and a .>? b +c would become (a.">?"(b))+c
bye Jochen
________________________________
If you reply to this email, your message will be added to the discussion below:
http://groovy.329449.n5.nabble.com/Custom-operator-for-Groovy-3-tp5736388p5736402.html
To unsubscribe from Custom operator for Groovy 3, click here<http://groovy.329449.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=5736388&code=cmVhbGJsdWVzdW5AaG90bWFpbC5jb218NTczNjM4OHwxMTQ2MjE4MjI1>.
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/Custom-operator-for-Groovy-3-tp5736388p5736407.html
Sent from the Groovy Dev mailing list archive at Nabble.com.
Re: Custom operator for Groovy 3
Posted by "Daniel.Sun" <re...@hotmail.com>.
Hi Jochen,
> "obj.hello('Daniel')"
My mail client translated the generics type to html tag, which is ignored... The example code is about generics method call.
> I expected conflicts with a.*x and a.?x, but not with an import.
The lexer will try to match as many characters as possible and make tokens, as a result, .* in the import statement is also recognized as custom operator. So I use ` instead for the time being.
Cheers,
Daniel.Sun
在 "Jochen Theodorou [via Groovy]" <ml...@n5.nabble.com>，2016年11月1日 下午10:17写道：
On 01.11.2016 02:39, Daniel.Sun wrote:
> Hi Jochen,
>
> I tried to implement custom operator based on your new idea and
> found it a bit ambiguous, e.g. ".<" is ambiguous to
> "obj.hello('Daniel')"
this I do not understand really, unless < can be part of an identifier
or an identifier can end with a dot, but the later would produce even
more ambiguity problems.
>, ".*" is ambiguous to "import java.util.*", etc.
I expected conflicts with a.*x and a.?x, but not with an import. Makes
me think the approach is maybe wrong. Where did you do the changes? Some
place as for thee `?
bye Jcohen
________________________________
If you reply to this email, your message will be added to the discussion below:
http://groovy.329449.n5.nabble.com/Custom-operator-for-Groovy-3-tp5736388p5736441.html
To unsubscribe from Custom operator for Groovy 3, click here<http://groovy.329449.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=5736388&code=cmVhbGJsdWVzdW5AaG90bWFpbC5jb218NTczNjM4OHwxMTQ2MjE4MjI1>.
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/Custom-operator-for-Groovy-3-tp5736388p5736442.html
Sent from the Groovy Dev mailing list archive at Nabble.com.
Re: Custom operator for Groovy 3
Posted by Jochen Theodorou <bl...@gmx.org>.
On 01.11.2016 02:39, Daniel.Sun wrote:
> Hi Jochen,
>
> I tried to implement custom operator based on your new idea and
> found it a bit ambiguous, e.g. ".<" is ambiguous to
> "obj.hello('Daniel')"
this I do not understand really, unless < can be part of an identifier
or an identifier can end with a dot, but the later would produce even
more ambiguity problems.
>, ".*" is ambiguous to "import java.util.*", etc.
I expected conflicts with a.*x and a.?x, but not with an import. Makes
me think the approach is maybe wrong. Where did you do the changes? Some
place as for thee `?
bye Jcohen
Re: Custom operator for Groovy 3
Posted by "Daniel.Sun" <re...@hotmail.com>.
Hi Jochen,
I tried to implement custom operator based on your new idea and found it a bit ambiguous, e.g. ".<" is ambiguous to "obj.hello('Daniel')", ".*" is ambiguous to "import java.util.*", etc. So I reserve the "`" notation for the time being.
To extend your new idea:
a `>?` b === a."`>?`"(b) // binary expression
the following syntax will be useful too:
`?` a === "`?`"(a) // unary expression
a `?` === a."`?`"() // postfix expression
As you can see, with double "`" quoted, all the three syntax are natural.
Any thoughts？ ;-)
Cheers,
Daniel.Sun
在 "Jochen Theodorou [via Groovy]" <ml...@n5.nabble.com>，2016年10月30日 下午8:16写道：
On 30.10.2016 11:07, Daniel.Sun wrote:
> Hi Paolo,
>
> There are some limitations when we use antlr to define grammar, so the
> backticks are used to distinguish with other operators.
>
> I saw an answer from Jochen(shown as follow), so I tryied to add this
> experimental feature
>
> "We always wanted the ability to define an operator through the user in
> Groovy, but so far we haven't gotten around the problems that come along
> with that."
> http://stackoverflow.com/questions/6485861/is-it-possible-to-define-a-new-operator-in-groovy/10848093#10848093
I actually gave up on custom operators for a bit.
In Scala you have a natural mapping of "a + b" to a."+"(b). But in
Groovy that would be a(+).b. That means binary expressions and command
expressions follow different patterns. That means in a+b+c we do not
naturally get (a+b)+c, we get a(+).b(+).c. This is what makes you
require special characters to distinguish operators and command
expressions in the usage of those
And if you change precedence rules like you described... a + b + c is
(a+b)+c while a + b "`x`" c would become a+(b "`x`" c) instead.
But to develop the idea... how about saying that everything between dot
and an identifier is an operator? So a .x c would be a.x(c).. well that
looks obvious, but a .>? c becomes a.">?"(c). This kind of logic would
reduce the need for special characters and be in line with existing
syntax. And at the same time precedence rule would be clear. a + b .>? c
would be a+(b.">?"(c)) and a .>? b +c would become (a.">?"(b))+c
bye Jochen
________________________________
If you reply to this email, your message will be added to the discussion below:
http://groovy.329449.n5.nabble.com/Custom-operator-for-Groovy-3-tp5736388p5736402.html
To unsubscribe from Custom operator for Groovy 3, click here<http://groovy.329449.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=5736388&code=cmVhbGJsdWVzdW5AaG90bWFpbC5jb218NTczNjM4OHwxMTQ2MjE4MjI1>.
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/Custom-operator-for-Groovy-3-tp5736388p5736431.html
Sent from the Groovy Dev mailing list archive at Nabble.com.
Re: Custom operator for Groovy 3
Posted by Jochen Theodorou <bl...@gmx.org>.
On 30.10.2016 11:07, Daniel.Sun wrote:
> Hi Paolo,
>
> There are some limitations when we use antlr to define grammar, so the
> backticks are used to distinguish with other operators.
>
> I saw an answer from Jochen(shown as follow), so I tryied to add this
> experimental feature
>
> "We always wanted the ability to define an operator through the user in
> Groovy, but so far we haven't gotten around the problems that come along
> with that."
> http://stackoverflow.com/questions/6485861/is-it-possible-to-define-a-new-operator-in-groovy/10848093#10848093
I actually gave up on custom operators for a bit.
In Scala you have a natural mapping of "a + b" to a."+"(b). But in
Groovy that would be a(+).b. That means binary expressions and command
expressions follow different patterns. That means in a+b+c we do not
naturally get (a+b)+c, we get a(+).b(+).c. This is what makes you
require special characters to distinguish operators and command
expressions in the usage of those
And if you change precedence rules like you described... a + b + c is
(a+b)+c while a + b "`x`" c would become a+(b "`x`" c) instead.
But to develop the idea... how about saying that everything between dot
and an identifier is an operator? So a .x c would be a.x(c).. well that
looks obvious, but a .>? c becomes a.">?"(c). This kind of logic would
reduce the need for special characters and be in line with existing
syntax. And at the same time precedence rule would be clear. a + b .>? c
would be a+(b.">?"(c)) and a .>? b +c would become (a.">?"(b))+c
bye Jochen
Re: Custom operator for Groovy 3
Posted by "Daniel.Sun" <re...@hotmail.com>.
The logic of custom operator is impelemented in a method, so the custom
operator is accually method call. The feature will not be added to Groovy,
so forget it ;-)
Cheers,
Daniel.Sun
--
View this message in context: http://groovy.329449.n5.nabble.com/Custom-operator-for-Groovy-3-tp5736388p5736405.html
Sent from the Groovy Dev mailing list archive at Nabble.com.
Re: Custom operator for Groovy 3
Posted by Maarten Boekhold <bo...@gmx.com>.
What if we look at this as a special kind of method call: in-fix method calls?
Maarten
On October 30, 2016 2:08:07 PM "Daniel.Sun" <re...@hotmail.com> wrote:
> Hi Paolo,
>
> There are some limitations when we use antlr to define grammar, so the
> backticks are used to distinguish with other operators.
>
> I saw an answer from Jochen(shown as follow), so I tryied to add this
> experimental feature
>
> "We always wanted the ability to define an operator through the user in
> Groovy, but so far we haven't gotten around the problems that come along
> with that."
> http://stackoverflow.com/questions/6485861/is-it-possible-to-define-a-new-operator-in-groovy/10848093#10848093
>
> BTW, this is a experimental feature and some traps may exist as
> C�dric said, so I'm not sure it will be added to Groovy 3 ;-)
>
>
> Cheers,
> Daniel.Sun
>
>
>
> --
> View this message in context:
> http://groovy.329449.n5.nabble.com/Custom-operator-for-Groovy-3-tp5736388p5736396.html
> Sent from the Groovy Dev mailing list archive at Nabble.com.
Re: Custom operator for Groovy 3
Posted by "Daniel.Sun" <re...@hotmail.com>.
Hi Paolo,
There are some limitations when we use antlr to define grammar, so the
backticks are used to distinguish with other operators.
I saw an answer from Jochen(shown as follow), so I tryied to add this
experimental feature
"We always wanted the ability to define an operator through the user in
Groovy, but so far we haven't gotten around the problems that come along
with that."
http://stackoverflow.com/questions/6485861/is-it-possible-to-define-a-new-operator-in-groovy/10848093#10848093
BTW, this is a experimental feature and some traps may exist as
Cédric said, so I'm not sure it will be added to Groovy 3 ;-)
Cheers,
Daniel.Sun
--
View this message in context: http://groovy.329449.n5.nabble.com/Custom-operator-for-Groovy-3-tp5736388p5736396.html
Sent from the Groovy Dev mailing list archive at Nabble.com.
Re: Custom operator for Groovy 3
Posted by Paolo Di Tommaso <pa...@gmail.com>.
Hi Daniel,
I haven't had realised the need of the backtick characters to define and
use custom operators. Still useful though much less *sexy* IMO.
Cheers,
Paolo
On Sun, Oct 30, 2016 at 10:30 AM, Daniel.Sun <re...@hotmail.com>
wrote:
> Hi Paolo,
>
> Here are some example code. As you see, the special character(`) is
> required to define the custom operator:
>
> // Custom operators should be declared first, then use.
> // It can be declared in the class or script, but it must be declared
> static.
> class A {
> static "`>?`"(int a, int b) {
> return Math.max(a, b);
> }
> }
>
> static "`<?`"(int a, int b) {
> return Math.min(a, b);
> }
>
> // Notice: the custom operator has higher priority to avoid parentheses in
> most cases
> assert 2 == 1 `>?` 2
> assert 1 == 1 `<?` 2
> assert 7 == (1 + 3) `>?` (2 + 5)
> assert 9 == 1 + 3 `>?` 2 + 5
>
>
>
> --
> View this message in context: http://groovy.329449.n5.
> nabble.com/Custom-operator-for-Groovy-3-tp5736388p5736394.html
> Sent from the Groovy Dev mailing list archive at Nabble.com.
>
Re: Custom operator for Groovy 3
Posted by "Daniel.Sun" <re...@hotmail.com>.
Hi Paolo,
Here are some example code. As you see, the special character(`) is
required to define the custom operator:
// Custom operators should be declared first, then use.
// It can be declared in the class or script, but it must be declared
static.
class A {
static "`>?`"(int a, int b) {
return Math.max(a, b);
}
}
static "`<?`"(int a, int b) {
return Math.min(a, b);
}
// Notice: the custom operator has higher priority to avoid parentheses in
most cases
assert 2 == 1 `>?` 2
assert 1 == 1 `<?` 2
assert 7 == (1 + 3) `>?` (2 + 5)
assert 9 == 1 + 3 `>?` 2 + 5
--
View this message in context: http://groovy.329449.n5.nabble.com/Custom-operator-for-Groovy-3-tp5736388p5736394.html
Sent from the Groovy Dev mailing list archive at Nabble.com.
Re: Custom operator for Groovy 3
Posted by Jochen Theodorou <bl...@gmx.org>.
On 30.10.2016 18:43, Russel Winder wrote:
> On Sun, 2016-10-30 at 10:06 +0100, C�dric Champeau wrote:
>> I'm -1 on adding custom operators. We always said we wouldn't fall
>> into the
>> same trap as C++ or Scala, but instead allow overriding existing
>> operators.
>
> I like custom operators as in Algol-68 and Scala. It is just that some
> Scala codes take things too far, showing a lack of self-restraint, and
> inability to read. This however is not a reason to abandon the idea.
> Consider that C++ and Python both restrict the overloading to the
> operators known to the compiler. Note that Java removed this because it
> was too hard for programmers to understand. Note that Groovy has
> reintroduced this because programmers wanted it. Also that Scala and
> Kotlin have followed suit and/or gone further.
>
> There is a balance between condescension and authoritarianism (which a
> number of programming languages are now following) and leaving it to
> the programmer to do the right thing at the risk of them not, but it is
> their problem. I am not a fan of condescending authoritarianism.
I think the biggest mistake is to allow the general overloading of "=".
Be it with some automated type coercion or another user over-writable
mechanism. We have to some extend for assignment to Boolean with
asBoolean, but not in general and not specialized for "=", especially
not for arbitrary types. I think it was a big mistake for Scala to
introduce something like this. It makes DSLs nicer, yes, but it makes it
incredibly difficult for the programmer to follow the program flow.
So if we add custom operators, we should ensure they fit in the general
program flow
bye Jochen
Re: Custom operator for Groovy 3
Posted by Russel Winder <ru...@winder.org.uk>.
On Sun, 2016-10-30 at 10:06 +0100, Cédric Champeau wrote:
> I'm -1 on adding custom operators. We always said we wouldn't fall
> into the
> same trap as C++ or Scala, but instead allow overriding existing
> operators.
I like custom operators as in Algol-68 and Scala. It is just that some
Scala codes take things too far, showing a lack of self-restraint, and
inability to read. This however is not a reason to abandon the idea.
Consider that C++ and Python both restrict the overloading to the
operators known to the compiler. Note that Java removed this because it
was too hard for programmers to understand. Note that Groovy has
reintroduced this because programmers wanted it. Also that Scala and
Kotlin have followed suit and/or gone further.
There is a balance between condescension and authoritarianism (which a
number of programming languages are now following) and leaving it to
the programmer to do the right thing at the risk of them not, but it is
their problem. I am not a fan of condescending authoritarianism.
--
Russel.
=============================================================================
Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder@ekiga.net
41 Buckmaster Road m: +44 7770 465 077 xmpp: russel@winder.org.uk
London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Re: Custom operator for Groovy 3
Posted by "Daniel.Sun" <re...@hotmail.com>.
Hi Cédric
> We always said we wouldn't fall into the same trap as C++ or Scala, but
> instead allow overriding existing operators.
Could you please expain the trap in details? Thanks in advance :)
BTW, I adjusted the priority of custom operators to avoid parentheses in
most cases.
https://github.com/danielsun1106/groovy-parser/blob/customOperator/src/test/resources/core/CustomOperator_01x.groovy
Cheers,
Daniel.Sun
--
View this message in context: http://groovy.329449.n5.nabble.com/Custom-operator-for-Groovy-3-tp5736388p5736393.html
Sent from the Groovy Dev mailing list archive at Nabble.com.
Re: Custom operator for Groovy 3
Posted by Cédric Champeau <ce...@gmail.com>.
I'm -1 on adding custom operators. We always said we wouldn't fall into the
same trap as C++ or Scala, but instead allow overriding existing operators.
Le 30 oct. 2016 10:03, "Paolo Di Tommaso" <pa...@gmail.com> a
écrit :
> This sounds a cool feature for DSL writers. What characters are eligible
> for custom operators?
>
>
> Cheers,
> Paolo
>
>
> On Sun, Oct 30, 2016 at 8:02 AM, 孙 岚 <re...@hotmail.com> wrote:
>
>> Hi all,
>>
>> The new parser support defining custom operator now. The initial
>> implementation is on the customOperator branch of groovy-parser(
>> https://github.com/danielsun1106/groovy-parser/tree/customOperator).
>>
>> Some examples can be found at https://github.com/danielsun11
>> 06/groovy-parser/blob/c3259607c4ee0cda6e5619bed35d0674e26f78
>> aa/src/test/resources/core/CustomOperator_01x.groovy
>>
>> In order to make the custom operator have more priorities, the
>> custom operators have lower priority by default, and the priority can be
>> changed by using parentheses.
>>
>> Any thoughts?
>>
>> Cheers,
>> Daniel.Sun
>>
>>
>>
>
Re: Custom operator for Groovy 3
Posted by Paolo Di Tommaso <pa...@gmail.com>.
This sounds a cool feature for DSL writers. What characters are eligible
for custom operators?
Cheers,
Paolo
On Sun, Oct 30, 2016 at 8:02 AM, 孙 岚 <re...@hotmail.com> wrote:
> Hi all,
>
> The new parser support defining custom operator now. The initial
> implementation is on the customOperator branch of groovy-parser(
> https://github.com/danielsun1106/groovy-parser/tree/customOperator).
>
> Some examples can be found at https://github.com/
> danielsun1106/groovy-parser/blob/c3259607c4ee0cda6e5619bed35d06
> 74e26f78aa/src/test/resources/core/CustomOperator_01x.groovy
>
> In order to make the custom operator have more priorities, the
> custom operators have lower priority by default, and the priority can be
> changed by using parentheses.
>
> Any thoughts?
>
> Cheers,
> Daniel.Sun
>
>
>