Mailing-List: contact users-help@groovy.incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@groovy.incubator.apache.org
Subject: Re: Command Chain in assert
To: users@groovy.incubator.apache.org
References: <5C676E6359909E478C7B811BDB48CA3542BFF9@CWWAPP478.windstream.com>
 <563E320C.4040305@gmx.net>
 <CAMbkE7QB38HaquTAoZgnm7Q3jNrarCLjScvdQSc2uDaHOvXt4w@mail.gmail.com>
 <5C676E6359909E478C7B811BDB48CA3542C522@CWWAPP478.windstream.com>
From: Jochen Theodorou <blackdrag@gmx.org>
Message-ID: <5640A7F2.1040004@gmx.org>
Date: Mon, 9 Nov 2015 15:04:34 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <5C676E6359909E478C7B811BDB48CA3542C522@CWWAPP478.windstream.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

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