Le 15 mars 2016 à 12:51, Guillaume Laforge <glaforge@gmail.com> a écrit :

It was indeed limited to top-level statements initially, but there have been cases where we felt it could be opened up.
Perhaps it's worth reopening the discussion.
For example, inside statements like if, or things like asserts, perhaps we could allow it?
Open for discussion on this.


+1

If I understand correctly, that would be nice for DSL, so instead of having 

boolean allAdults = every member of familyComposition is ADULT
if (allAdults) { ... }

we could have

if (every member of familyComposition is ADULT) { ... }

(with the proper dsl wired in of course).


On Tue, Mar 15, 2016 at 5:45 PM, Дионисьев Павел <xseagullx@gmail.com> wrote:

Dear Jesper,

As far as I remember, command expressions are allowed as statements only. There will be lots of ambiguities otherwise.

Also, there are known issues in grammar, listed in original repository. You might want to have a look and incorporate them in your issue tracker.

And thank you for working on this project!

Pavel.


On 15 March 2016 at 17:22, Jesper Steen Møller <jesper@selskabet.org> wrote:
Hi List

I’ve yet to fully understand the rules behind the parenthesis-less method invocation syntax. Basically, it seems that while parenthesis-less method invocation (“command style”) can sometimes be used as an expression, it’s not universally so.

I’d like to understand whether this is a merely an oversight or due to the current state of affairs in the parser, or intentional.

Consider:
int a = b c
This is legal and equivalent to
int a = b(c)
similarly:
a = b c
Works fine, too, letting “b c” be a valid expression.
However, the following:
if (b c) {
// Stuff
}
Gives an error:
expecting ‘)’, found ‘c’ at line: 1, column: 11

So, is the “command” syntax a special pseudo-expression, and if so, where is it allowed? Only by itself (“statement”), and as the RHS og assignments and initializers?

I’d like to know this as it could get real nasty, depending on the answer, since allowing it everywhere will introduce some ambiguities, which will require some tweaks to keep the “non-left-recursion refactored” grammar we have now.

Also, great news:
Daniel Sun has started contributing fixes, submitting PR’s against the fork at https://github.com/jespersm/groovy/tree/antlr4 - he’s quite productive, thanks!

For coordination, I’ve started tracking some of the known “things to do” at https://github.com/jespersm/groovy/issues

-Jesper




--
С уважением, Дионисьев П.А.



--
Guillaume Laforge
Apache Groovy committer & PMC Vice-President
Product Ninja & Advocate at Restlet