Additionally, you are forcing the hand of users in terms of brace style if you
require a closure to have its opening brace on the same line as the method
call/name.
-----Original Message-----
From: Milles, Eric (TR Tech, Content & Ops) <eric.mil...@thomsonreuters.com>
Sent: Saturday, March 28, 2020 10:20 AM
To: dev@groovy.apache.org
Subject: RE: About eliminating ambiguities of method call with closure argument
Is there any language that differentiates between one space and multiple
whitespaces as a separator? My experience with C, C++, Java, Groovy, etc. is
that any number of whitespaces are the same in terms of separation between
tokens.
In terms of parsing, you can't tell that an identifier is a method name -- you
mention below closure follows method name -- you don't know until semantic
analysis and possibly runtime in terms of dynamic Groovy if an identifier
refers to a method name.
Can the user insert a semicolon to disambiguate?
```
a | meth ; // now the parser knows this statement is over { p -> } ```
I don't think you are ever going to see an end to ambiguous constructs due to
optional parentheses and semicolons.
-----Original Message-----
From: Daniel.Sun <sun...@apache.org>
Sent: Friday, March 27, 2020 10:06 PM
To: d...@groovy.incubator.apache.org
Subject: About eliminating ambiguities of method call with closure argument
Hi all,
Current groovy grammar of method call contains the following
ambiguities, which are odd for users. For example,
1) method call with closure argument. That means the closure on the next line
could be treated as argument of method `meth` ``` meth { p -> } ```
2) binary expression and closure expression. That means the closure is not an
argument.
```
a | meth
{ p ->
}
```
I propose to unify the grammar of closure arguments: when closure
follows method name directly, it is an argument, otherwise it is just
standalone closure. For example,
3) method call with closure argument
```
meth { p ->
}
```
4) variable and closure
```
meth
{ p ->
}
```
Luckily, groovy-parser project containing source code of some famous
groovy projects, none of which are broken because of the proposed change[1].
Here is a JIRA ticket[2] to track the proposed change, and here is the
PR[3] to implement the change.
Any thoughts?
Cheers,
Daniel Sun
[1]
https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fdanielsun1106%2Fgroovy-parser%2Fcommits%2FGROOVY-9484&data=02%7C01%7Ceric.milles%40thomsonreuters.com%7C55746422d5ec42d281f508d7d32b7c3a%7C62ccb8646a1a4b5d8e1c397dec1a8258%7C0%7C0%7C637210056033516926&sdata=lnEsUtHUU%2FqUXzlEvJA41AkWkXX0g6Ur2o2b5Vye3bM%3D&reserved=0
[2]
https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissues.apache.org%2Fjira%2Fbrowse%2FGROOVY-9484&data=02%7C01%7Ceric.milles%40thomsonreuters.com%7C55746422d5ec42d281f508d7d32b7c3a%7C62ccb8646a1a4b5d8e1c397dec1a8258%7C0%7C0%7C637210056033526920&sdata=fVNF6la9ogHDBgM8uj%2FstRAqnUUXThrlHq%2BEdK7Qq%2BY%3D&reserved=0
[3]
https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgroovy%2Fpull%2F1211&data=02%7C01%7Ceric.milles%40thomsonreuters.com%7C55746422d5ec42d281f508d7d32b7c3a%7C62ccb8646a1a4b5d8e1c397dec1a8258%7C0%7C0%7C637210056033526920&sdata=alJQcVNgAdYlyLyk%2FpD%2BBMo3dLGKhwqlkV3LTbR%2BxS8%3D&reserved=0
-----
Apache Groovy committer & PMC member
Blog:
https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fblog.sunlan.me&data=02%7C01%7Ceric.milles%40thomsonreuters.com%7C55746422d5ec42d281f508d7d32b7c3a%7C62ccb8646a1a4b5d8e1c397dec1a8258%7C0%7C0%7C637210056033526920&sdata=IQu4X3%2BFtC7BAVDSqKqGnAcgkicXXiI8XLH8mqI4g8s%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%7C55746422d5ec42d281f508d7d32b7c3a%7C62ccb8646a1a4b5d8e1c397dec1a8258%7C0%7C0%7C637210056033526920&sdata=jEmfYhHiJgpJJePXCtrIl9pChfqfBlWSPv4ebp%2FpliY%3D&reserved=0
