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" <su...@apache.org> on 2020/05/07 23:43:12 UTC
About eliminating ambiguities safe indexing and ternary expression
Hi all,
Safe indexing has been introduced since Groovy 3.0.0, it is useful but
confuses both parser and users sometimes because it is not a real operator
in order to not breaking existing code as possible as we could. For example,
```
// https://issues.apache.org/jira/browse/GROOVY-9522
def a() { null }
def b() { '' }
a()?[b(), a()].join(','):b() // statement with ambiguities
```
The above statement with ambiguities can be parsed into:
1) safe indexing expression, `a()?[[b(), a()]].join([',': b()])`
2) ternary expression, `a() ? ([b(), a()].join(',')) : b()`
As safe indexing(i.e. `?[`) has same precedence with safe reference(i.e.
`?.`), safe indexing has higher precedence than ternary expression. When
ambiguities appear, the expression with ambiguities will be parsed into safe
indexing. As a result, the potential issue is hard for user to find early
and is ususally found when code has been executed...
So I propose to make safe indexing operator `?[` become a real operator,
i.e. it will be defined in the groovy lexer.
* pros:
1) No ambiguities
2) Better parsing performance
* cons:
1) Breaking some existing ternary expressions without spaces between`?` and
`[`, e.g. `true?[0] : [1]` will be broken, so it has to be rewritten to
`true? [0] : [1]`
As Groovy 3 has been released, I proposed to apply the change to Groovy 4.
Any thoughts?
Cheers,
Daniel Sun
-----
Apache Groovy committer & PMC member
Blog: http://blog.sunlan.me
Twitter: @daniel_sun
--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
RE: About eliminating ambiguities safe indexing and ternary
expression
Posted by "Milles, Eric (TR Tech, Content & Ops)" <er...@thomsonreuters.com>.
I doubt the vote for release really included detailed consideration for each individual change in a release that was years in the making. I am restating concern for specific features and the fact that discussion was not held. My concern is that we got away from Groovy 2.6 which provided a step forward with the availability of the Antlr4 parser with no new syntax additions.
I am not saying disable the Parrot Parser; I am saying disable safe indexing until such time that fixes for known breaking changes are made or there is sufficient consensus that the new behaviors are acceptable vs compatibility/predictability.
I am also not saying halt innovation. I am saying that new innovations like syntax changes need a little more time to incubate and be reviewed. Like java offers preview features. If you don't want 'em you do not need to enable them. I don't think the uptake in the community of nightly builds, betas, and release candidates is that great. So you need a full production release to gain exposure. Now you have that with the Parrot Parser and there some issues to work out. But for the user, it's either Parrot Parser on or Parrot Parser off. There isn't a middle ground -- a way to disable any of the new syntax additions in case they conflict with existing source code.
-----Original Message-----
From: Daniel.Sun <su...@apache.org>
Sent: Saturday, May 9, 2020 3:14 PM
To: dev@groovy.incubator.apache.org
Subject: RE: About eliminating ambiguities safe indexing and ternary expression
The vote for releasing Groovy 3 has passed with at least three +1 from PMC members. In other words, all of changes of Groovy 3 have been reviewed and not incubating any more.
As to safe indexing, we have to admit we missed some scenarios to check, so the ambiguities are introduced by accident. But we can tweak it as I proposed and not just disable the feature because of some glitch. Further more, though the new Parrot parser can keep compatible with the old parser at most cases and passes tons of tests, but no one can assure 100% compatibility, so in order to avoid potential issue, we should disable or remove Parrot parser in Groovy 3? No, we will try our best to weak it. Same logic to safe indexing. Also, I think we all understand Groovy is not a toy.
At last but not least, I really worry about the future of Groovy programming. If it just chases the steps of Java, it will just be another Java with some existing its own features inherited from Groovy elders, e.g.
Guillaume, Jochen, Cedric, Paul, etc.
(My 2 cents)
Cheers,
Daniel Sun
-----
Apache Groovy committer & PMC member
Blog: https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fblog.sunlan.me%2F&data=02%7C01%7Ceric.milles%40thomsonreuters.com%7Cb1f729ec40494a557eb708d7f45585a6%7C62ccb8646a1a4b5d8e1c397dec1a8258%7C0%7C0%7C637246520462053907&sdata=7PAmqGQJZhDhemJ58oI2mFh%2Fgwnz3uaz8qpN3SH80HY%3D&reserved=0
Twitter: @daniel_sun
--
Sent from: https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fgroovy.329449.n5.nabble.com%2FGroovy-Dev-f372993.html&data=02%7C01%7Ceric.milles%40thomsonreuters.com%7Cb1f729ec40494a557eb708d7f45585a6%7C62ccb8646a1a4b5d8e1c397dec1a8258%7C0%7C0%7C637246520462053907&sdata=mCT%2FNfzj6hPhQTny3UIWYVL1LB2Qt%2BG15xq0U7K4pf8%3D&reserved=0
RE: About eliminating ambiguities safe indexing and ternary
expression
Posted by "Daniel.Sun" <su...@apache.org>.
The vote for releasing Groovy 3 has passed with at least three +1 from PMC
members. In other words, all of changes of Groovy 3 have been reviewed and
not incubating any more.
As to safe indexing, we have to admit we missed some scenarios to check, so
the ambiguities are introduced by accident. But we can tweak it as I
proposed and not just disable the feature because of some glitch. Further
more, though the new Parrot parser can keep compatible with the old parser
at most cases and passes tons of tests, but no one can assure 100%
compatibility, so in order to avoid potential issue, we should disable or
remove Parrot parser in Groovy 3? No, we will
try our best to weak it. Same logic to safe indexing. Also, I think we all
understand Groovy is not a toy.
At last but not least, I really worry about the future of Groovy
programming. If it just chases the steps of Java, it will just be another
Java with some existing its own features inherited from Groovy elders, e.g.
Guillaume, Jochen, Cedric, Paul, etc.
(My 2 cents)
Cheers,
Daniel Sun
-----
Apache Groovy committer & PMC member
Blog: http://blog.sunlan.me
Twitter: @daniel_sun
--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
RE: About eliminating ambiguities safe indexing and ternary
expression
Posted by "Milles, Eric (TR Tech, Content & Ops)" <er...@thomsonreuters.com>.
This discussion has been held before. From my perspective, safe indexing was/is an incubating feature. I think that "x.?getAt(y)" is readily available in place of "x?[y]" shorthand.
And with significant chance for interpreting existing code in a different way, I think it needs to be disabled until the ambiguity can be sorted out. I think it is a reasonable expectation for any developer to take existing Groovy 2 code and move it to Groovy 3 with no change in parsing or semantics. At the very least, an option to disable parsing of '?' followed by '[' as safe indexing to they can get back to prior semantics should be provided.
Before enabling safe indexing again, I would expect quite a large test suite that includes map and list literals as well as ternary operators.
Safe indexing and elvis assignment fall into the group of new features that I requested to be discussed before inclusion in the final release [1]. They have the feeling of "because we can" and don't appear to have been put through rigorous testing and critical review. Such a discussion was promised but never held (see "New syntax explosion" thread on the mailing list -- link below).
[1] http://mail-archives.apache.org/mod_mbox/groovy-dev/201710.mbox/%3C2BA8478A2FBAFF4FBFDF1724FAD8C09E8C817AFE%40C111BKGPMBX48.ERF.thomson.com%3E
-----Original Message-----
From: Daniel.Sun <su...@apache.org>
Sent: Thursday, May 7, 2020 6:43 PM
To: dev@groovy.incubator.apache.org
Subject: About eliminating ambiguities safe indexing and ternary expression
Hi all,
Safe indexing has been introduced since Groovy 3.0.0, it is useful but confuses both parser and users sometimes because it is not a real operator in order to not breaking existing code as possible as we could. For example,
```
// https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissues.apache.org%2Fjira%2Fbrowse%2FGROOVY-9522&data=02%7C01%7Ceric.milles%40thomsonreuters.com%7C9a98288c04454277352808d7f2e06e45%7C62ccb8646a1a4b5d8e1c397dec1a8258%7C0%7C0%7C637244918047726423&sdata=5AvALvtyOtYXRW4O81TSPoBdQcbq7RoO6veqrPwG3gU%3D&reserved=0
def a() { null }
def b() { '' }
a()?[b(), a()].join(','):b() // statement with ambiguities ``` The above statement with ambiguities can be parsed into:
1) safe indexing expression, `a()?[[b(), a()]].join([',': b()])`
2) ternary expression, `a() ? ([b(), a()].join(',')) : b()`
As safe indexing(i.e. `?[`) has same precedence with safe reference(i.e.
`?.`), safe indexing has higher precedence than ternary expression. When ambiguities appear, the expression with ambiguities will be parsed into safe indexing. As a result, the potential issue is hard for user to find early and is ususally found when code has been executed...
So I propose to make safe indexing operator `?[` become a real operator, i.e. it will be defined in the groovy lexer.
* pros:
1) No ambiguities
2) Better parsing performance
* cons:
1) Breaking some existing ternary expressions without spaces between`?` and `[`, e.g. `true?[0] : [1]` will be broken, so it has to be rewritten to `true? [0] : [1]`
As Groovy 3 has been released, I proposed to apply the change to Groovy 4.
Any thoughts?
Cheers,
Daniel Sun
-----
Apache Groovy committer & PMC member
Blog: https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fblog.sunlan.me%2F&data=02%7C01%7Ceric.milles%40thomsonreuters.com%7C9a98288c04454277352808d7f2e06e45%7C62ccb8646a1a4b5d8e1c397dec1a8258%7C0%7C0%7C637244918047726423&sdata=Kcoqh2FbJNmu3jfGURK3fEN4986JLqFPWbYGe539x%2Fw%3D&reserved=0
Twitter: @daniel_sun
--
Sent from: https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fgroovy.329449.n5.nabble.com%2FGroovy-Dev-f372993.html&data=02%7C01%7Ceric.milles%40thomsonreuters.com%7C9a98288c04454277352808d7f2e06e45%7C62ccb8646a1a4b5d8e1c397dec1a8258%7C0%7C0%7C637244918047736421&sdata=zo0O%2FtdotT6e9kYvckMm2iwwndUORke2MBnkWYh34dE%3D&reserved=0
Re: About eliminating ambiguities safe indexing and ternary
expression
Posted by "Daniel.Sun" <su...@apache.org>.
Yep ;-)
Optional parentheses is nice to DSL but introduces some ambiguities too :-(
Cheers,
Daniel Sun
-----
Apache Groovy committer & PMC member
Blog: http://blog.sunlan.me
Twitter: @daniel_sun
--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
Re: About eliminating ambiguities safe indexing and ternary
expression
Posted by Jochen Theodorou <bl...@gmx.org>.
On 08.05.20 04:36, J. David Beutel wrote:
[...]
> but how does the .join(','):b() part get parsed into .join([',': b()])?
write it like this:
foo.bar x:y
where x is (','), y is b() and bar is join. And this is equal to (thanks
to optional parentheses):
foo.bar([x:y])
bye Jochen
Re: About eliminating ambiguities safe indexing and ternary expression
Posted by "J. David Beutel" <li...@getsu.com>.
On 2020-05-07 13:43 , Daniel.Sun wrote:
> ```
> // https://issues.apache.org/jira/browse/GROOVY-9522
> def a() { null }
> def b() { '' }
> a()?[b(), a()].join(','):b() // statement with ambiguities
> ```
> The above statement with ambiguities can be parsed into:
> 1) safe indexing expression, `a()?[[b(), a()]].join([',': b()])`
> 2) ternary expression, `a() ? ([b(), a()].join(',')) : b()`
>
I'm not familiar with the new syntax, and this may be beside the point,
but how does the .join(','):b() part get parsed into .join([',': b()])?
Cheers,
11011011