> On Mar 29, 2020, at 0:19, Milles, Eric (TR Tech, Content & Ops)
> <eric.mil...@thomsonreuters.com> wrote:
>
> 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.
Not really:
String accepted = "a" +
"b" // works, gives "ab"
String bad = "a"
+ "b" // compile error
So, white space is significant in Groovy.
>
> 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%7Cbc5bd8c149104982c52b08d7d2c503df%7C62ccb8646a1a4b5d8e1c397dec1a8258%7C0%7C0%7C637209615925168880&sdata=qdhNufAqJP8kpOtsz1QWwz2b06pR%2F1v5loQnNcuWWRM%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%7Cbc5bd8c149104982c52b08d7d2c503df%7C62ccb8646a1a4b5d8e1c397dec1a8258%7C0%7C0%7C637209615925168880&sdata=Z3FyviGcsG4EtvIGiAv889dG%2F2p%2FhqClAED998%2BnT98%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%7Cbc5bd8c149104982c52b08d7d2c503df%7C62ccb8646a1a4b5d8e1c397dec1a8258%7C0%7C0%7C637209615925168880&sdata=iXdv8OT3BMIyno8R3TlLclEB1%2BSd%2BxPlCaxhacydSqA%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%7Cbc5bd8c149104982c52b08d7d2c503df%7C62ccb8646a1a4b5d8e1c397dec1a8258%7C0%7C0%7C637209615925168880&sdata=70Xxc7%2Bg6iF7bhVISTRF48hxQkUb5%2F7iuuofMttDF2o%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%7Cbc5bd8c149104982c52b08d7d2c503df%7C62ccb8646a1a4b5d8e1c397dec1a8258%7C0%7C0%7C637209615925168880&sdata=bGnd%2BrQj%2FPKljTtkIdT2fFyGF9aQb0QgR1RzQlWRPsY%3D&reserved=0
