[jira] [Updated] (GROOVY-9936) Difference between Antlr2 and parrot parsers for variable declaration optimisation

["Paul King (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/GROOVY-9936?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paul King updated GROOVY-9936:
------------------------------
    Description: 
As an optimisation for parsing, both parsers treat statements like:
{code}
int var1
Foo var2
Bar var3
{code}
as variable declarations due to the starting capital letter of the first term (for non-primitives).

And the following are treated by both parsers as command expressions:
{code}
foo x
bar y
{code}
due to the lowercase starting letter of the first term. If a class starts with a lowercase letter (valid though not conventional) the workaround is to use something like:
{code}
import myClass as MyClass

MyClass foo
{code}

A difference in behavior can be noted for cases starting with underscore or dollar (the only other characters available for the first letter of a class name):
{code}
_foo bar
$bar baz
{code}
These were command expression for the old parser and are being coerced to variable declarations in the Parrot parser.

We need to decide whether to alter these last two cases for backwards compatibility or whether we see this as a breaking change which better aligns with the Java specification.
I propose we opt for backwards compatibility since the above mentioned workaround would apply equally for classes with these starting characters but renaming a method starting with these characters is more complicated.

  was:
As an optimisation for parsing, both parsers treat statements like:
{code}
int var1
Foo var2
Bar var3
{code}
as variable declarations due to the starting capital letter of the first term (for non-primitives).

And the following are treated by both parsers as command expressions:
{code}
foo x
bar y
{code}
due to the lowercase starting letter of the first term. If

A difference in behavior can be noted for cases starting with underscore or dollar (the only other characters available for the first letter of a class name):
{code}
_foo bar
$bar baz
{code}
These were command expression for the old parser and are being coerced to variable declarations in the Parrot parser.

We need to decide whether to alter these last two cases for backwards compatibility or whether 


> Difference between Antlr2 and parrot parsers for variable declaration optimisation
> ----------------------------------------------------------------------------------
>
>                 Key: GROOVY-9936
>                 URL: https://issues.apache.org/jira/browse/GROOVY-9936
>             Project: Groovy
>          Issue Type: Bug
>          Components: parser-antlr4
>            Reporter: Paul King
>            Assignee: Paul King
>            Priority: Major
>
> As an optimisation for parsing, both parsers treat statements like:
> {code}
> int var1
> Foo var2
> Bar var3
> {code}
> as variable declarations due to the starting capital letter of the first term (for non-primitives).
> And the following are treated by both parsers as command expressions:
> {code}
> foo x
> bar y
> {code}
> due to the lowercase starting letter of the first term. If a class starts with a lowercase letter (valid though not conventional) the workaround is to use something like:
> {code}
> import myClass as MyClass
> MyClass foo
> {code}
> A difference in behavior can be noted for cases starting with underscore or dollar (the only other characters available for the first letter of a class name):
> {code}
> _foo bar
> $bar baz
> {code}
> These were command expression for the old parser and are being coerced to variable declarations in the Parrot parser.
> We need to decide whether to alter these last two cases for backwards compatibility or whether we see this as a breaking change which better aligns with the Java specification.
> I propose we opt for backwards compatibility since the above mentioned workaround would apply equally for classes with these starting characters but renaming a method starting with these characters is more complicated.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)