groovy-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Winnebeck, Jason" <>
Subject RE: Command Chain in assert
Date Mon, 09 Nov 2015 15:09:19 GMT
OK, thanks for insight into the problem. The idea from
to allow command chains in parens is a good one though, in all cases discussed so far it is
a possible solution, and it doesn't preclude Groovy from implementing smarter logic in the
future when parens are not present if a reasonable, unambiguous solution is discovered. For
the problem you described about multiple interpretation of foo x == bar y, that sounds more
like an operator precedence problem. I realize command chains are not exactly "operators,"
but in my mind I think of it in the same way -- does chaining take precedence over a binary
operator or not? It seems reasonable that some choice can be made there, and if you want a
different choice, you use parens just like any other case, and some can consider parens to
be required to be good style as in the case of (A && B || C) -- the compiler says
&& comes before || but as a developer I am always forgetting if && comes before
|| so as a matter of style I always use parens -- either (A && B) || C or A &&
(B||C). I think the same argument could apply to operators within command chains -- pick one
way and require parens for the other.


-----Original Message-----
From: Jochen Theodorou [] 
Sent: Monday, November 09, 2015 9:05 AM
Subject: Re: Command Chain in assert

On 09.11.2015 14:29, Winnebeck, Jason wrote:
> That ticket was useful. Just out of curiosity, is there a way to make 
> the DSL work if I do provide a function assert? I’m not sure it could, 
> because you’d need to support operators, and also when I tried to make 
> such a DSL I was not able to actually declare any symbol assert and be 
> able to call it how I’d expect. Even if it worked you’d lose power 
> assert. I wonder (not that I think it would be worth it) if it’s even 
> possible to implement with an AST? I’m thinking even that is not 
> possible because Groovy can’t even parse the syntax so you’d never get 
> to AST stage.

transforms still require that the program can be parsed... so no, it would not work with them

as for the problem itself... let me try making an example...

assert foo x == bar y

you interpret that as

assert foo(x) == bar(y)

but the compiler can interpret that as

assert foo(x==bar).y

In short the grammar cannot easily know which of those two is the right thing, especially
since both variants are valid.

We actually had maybe a similar problem with handling of = in asserts. 
As you may know doing something like "assert x=1" will not be accepted by the compiler. To
solve this we basically changed the rule in the grammar from

"assert" expression


"assert" assignmentLessExpression

with the later one being a sub rule that contains any expression minus assignment. So to solve
the issue in a similar way we would need something like this:

"assert" assignmentAndEqualsLessExpression ( "==" expression)?

where assignmentAndEqualsLessExpression does, in a similar matter, no allow for expressions
with directly a == in it.

And now the big trouble.... the command chain rules are not of that kind. They allow "=="
and such. In short, it is by no simple change and will affect a lot of rules... One of the
reasons I would like to simplify the compiler and let it accept more code, which could be
wrong, and filter it after parsing... but well... time and money speak against it atm.

bye blackdrag

This email message and any attachments are for the sole use of the intended recipient(s).
Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the
intended recipient, please contact the sender by reply email and destroy all copies of the
original message and any attachments.
View raw message