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
