parser problem?

["ocs@ocs.cz" <oc...@ocs.cz>]

Hi there,

lately, I have upgraded to Groovy 3.0.3 from 2.4.17, and have found expressions like this one:

1>2?[3] as Set:null

which used to be parsed properly by Groovy 2 do not work anymore. It can be fixed by enclosing the [3] as Set into parentheses, but of course it's a bit at the inconvenient side, given the number of sources I build my application from.

Did I miss some intentional breaking change, or is it a parser bug?

Thanks,
OC

Re: parser problem?

[OCsite <oc...@ocs.cz>]

Daniel,

just for the record, the problem occurs with “1>2?[3] as Set:null” and similar expressions. It is not caused, far as I understand, solely by “as”, but rather by a combination with the “safe” (non-NPE) indexing syntax, as Paul mentioned before.

> On 16 May 2020, at 2:51, Daniel.Sun <su...@apache.org> wrote:
> `as` can be used as identifier... but it is a keyword in the meantime...
> We can eliminate the ambiguities by stopping supporting `as` used as
> identifier.

Myself, I'd vote against: it would bring another breaking change for legacy sources which happen to use “as” for an identifier. Perhaps I do that myself, too; difficult to say, the codebase's big and offhand I can't see a reasonable regexp to check :)

If the aforementioned problem with “1>2?[3] as Set:null” is difficult to solve, I'd recommend to let it lay as a known bug with an extremely low priority to fix: it is a very rare case and very easily solved (adding a pair of parentheses is considerably easier and less error-prone than renaming variables, which might be needed in case of “as” not useable anymore).

(I'll try to get to adding a ticket for that ASAP, but I've got this week-end pretty busy, and first thing I need to do is test the snapshot with the joint-compilation fix — for which I'm very grateful, thanks!)

Thanks and all the best,
OC

Re: parser problem?

["Daniel.Sun" <su...@apache.org>]

`as` can be used as identifier... but it is a keyword in the meantime...
We can eliminate the ambiguities by stopping supporting `as` used as
identifier.

Cheers,
Daniel Sun



-----
Apache Groovy committer & PMC member 
Blog: http://blog.sunlan.me 
Twitter: @daniel_sun 

--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Users-f329450.html

Re: parser problem?

[OCsite <oc...@ocs.cz>]

Hi there,

> On 16 May 2020, at 2:41, Paul King <pa...@asert.com.au> wrote:
> I'd suggest creating an issue for this. We might be able to improve Groovy or if not we should assess whether the current doco around safe indexing explains possible interactions well enough.

GROOVY-9561 <https://issues.apache.org/jira/browse/GROOVY-9561>

Aside of that, it seems mails sent by me during the week-end did not make it to the maillist at all for some reason? Weird.

Anyway, perhaps a bit at the important side, I've been bitten in my tender parts pretty hard by the breaking change of the push/pop behaviour, which far as I understand happened in 2.5.0 to make Groovy more similar to Java (which I can't see as a reasonable goal, given the Groovy's very reason for existence is the Java intrinsic... well, let's say inconvenience :))

The thing is mentioned in the breaking changes in a rather offhand way as “same linkedlist code different behavior between groovy and java”, which I did not pursue, for I never share a list in a code in both the languages.

Alas it breaks pure Groovy code too, and in an ugly way (like e.g., “def list=[];list.push(1); list.push(2); assert list.last()==2”) and thus in my opinion should be reformulated in the release notes to something more apt like e.g., “the push/pop behaviour was changed to add/remove from the head of the list instead of its tail as it used to be before”.

Another small issue is that it seems the newest compiler does not recongise the --indy switch at all and aborts compilation seeing it. I understand indy does not make sense for 4+ anymore, but for project and buildchain backward compatibility it should recognise the switch and just emit a warning that the switch is ignored.

I don't really think these issues are worth a ticket; if you think otherwise, let me please know and I'll gladly add them.

Thanks a lot,
OC

Re: parser problem?

[Paul King <pa...@asert.com.au>]

You might want to try Script -> Inspect CST. Currently the parser doesn't
see the ternary operator at all. Currently, "2?[3]" is seen as a valid term
for safe indexing even though we know as humans that "2" is just a literal
and wouldn't be allowed here.
Currently, you can use "1>2?([3] as Set):null" to get around the problem. I
don't know if Daniel has some further suggestions. He had some changes in
this area in mind but I am not sure they help here.

I'd suggest creating an issue for this. We might be able to improve Groovy
or if not we should assess whether the current doco around safe indexing
explains possible interactions well enough.

Cheers, Paul.


On Sat, May 16, 2020 at 3:08 AM ocs@ocs.cz <oc...@ocs.cz> wrote:

> Hi there,
>
> lately, I have upgraded to Groovy 3.0.3 from 2.4.17, and have found
> expressions like this one:
>
> 1>2?[3] as Set:null
>
> which used to be parsed properly by Groovy 2 do not work anymore. It can
> be fixed by enclosing the [3] as Set into parentheses, but of course it's a
> bit at the inconvenient side, given the number of sources I build my
> application from.
>
> Did I miss some intentional breaking change, or is it a parser bug?
>
> Thanks,
> OC
>
>