OK, thanks for insight into the problem. The idea from https://issues.apache.org/jira/browse/GROOVY-4808 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.
Jason -----Original Message----- From: Jochen Theodorou [mailto:blackd...@gmx.org] Sent: Monday, November 09, 2015 9:05 AM To: users@groovy.incubator.apache.org 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 to "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.
