Re: About the groovy code style

[MG]

Two questions:

1. Jochen says "Danil  is doing special things with DSL", but "Daniil
   Ovchinnikov" replied regarding IntelliJ Groovy parsing. So is Danil
   == Daniil ?
2. I neither like nor use these syntax varieties - but wouldn't
   changing any of that behavior potentially break Groovy DSLs from
   here to Baghdad (not only "Danil"'s) ?-)

Cheers,
mg


On 04.07.2018 20:40, Paul King wrote:


Comment inline.

On Tue, Jul 3, 2018 at 10:31 PM Jochen Theodorou > wrote:




Am 03.07.2018 um 04:44 schrieb Daniel.Sun:
> Hi all,
>
>       The following code is supported in the older parser, but I
propose to
> stop supporting the ugly code style in the new Parrot parser.
Any thoughts?
>
> 1) import statement (
https://issues.apache.org/jira/browse/GROOVY-8642 )
> ```
> import java.
> lang.
> Object
> ```
>
> 2) prefix operator (
https://issues.apache.org/jira/browse/GROOVY-8650 )
> ```
> def c = --
> 1

I do not need these.. but since I know Danil is doing special things
with DSL, maybe we should first ask him if he needs that and why


Jochen, even though you say you "do not need these", the real question 
is what set of rules are you replacing the existing conceptual rule with?


Existing rule: if the set of tokens parsed when an end of line is 
reached doesn't make a complete expression/statement, continue reading 
tokens as if the EOL wasn't there.


There are exceptions, e.g. we currently don't allow single quote and 
single double quoted strings to span multiple lines but the list is short.


What are your new rules and new list of exceptions?

We shouldn't be tied down by our existing set of rules but we want to 
keep them simple for our users so they all don't need to be grammar 
experts to use the language.


Cheers, Paul.

bye Jochen

Re: About the groovy code style

[Paul King]

Comment inline.

On Tue, Jul 3, 2018 at 10:31 PM Jochen Theodorou  wrote:

>
>
> Am 03.07.2018 um 04:44 schrieb Daniel.Sun:
> > Hi all,
> >
> >   The following code is supported in the older parser, but I propose
> to
> > stop supporting the ugly code style in the new Parrot parser. Any
> thoughts?
> >
> > 1) import statement ( https://issues.apache.org/jira/browse/GROOVY-8642
> )
> > ```
> > import java.
> > lang.
> > Object
> > ```
> >
> > 2) prefix operator ( https://issues.apache.org/jira/browse/GROOVY-8650 )
> > ```
> > def c = --
> > 1
>
> I do not need these.. but since I know Danil is doing special things
> with DSL, maybe we should first ask him if he needs that and why
>

Jochen, even though you say you "do not need these", the real question is
what set of rules are you replacing the existing conceptual rule with?

Existing rule: if the set of tokens parsed when an end of line is reached
doesn't make a complete expression/statement, continue reading tokens as if
the EOL wasn't there.

There are exceptions, e.g. we currently don't allow single quote and single
double quoted strings to span multiple lines but the list is short.

What are your new rules and new list of exceptions?

We shouldn't be tied down by our existing set of rules but we want to keep
them simple for our users so they all don't need to be grammar experts to
use the language.

Cheers, Paul.


> bye Jochen
>

Re: About the groovy code style

[Daniel.Sun]

Hi Daniil,

OK. I see.
I am not going to support the ugly code style... but I want to know what
others think about :-)

Cheers,
Daniel.Sun



-
Daniel Sun 
Apache Groovy committer 
Blog: http://blog.sunlan.me 
Twitter: @daniel_sun 

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

Re: About the groovy code style

[Daniil Ovchinnikov]

Each introduced change make tooling more complicated. While some constructs 
become invalid in newer compiler, IntelliJ still has to support all Groovy 
versions.

So in IntelliJ we will continue to parse as in old version, but I’ll have to 
add error highlighting and tweak formatter for 3.0, unless you decide to 
support such corner cases in 3.0. 
—

Daniil Ovchinnikov
JetBrains


> On 4 Jul 2018, at 14:27, Daniel.Sun  wrote:
> 
> Yep. Daniil.
> 
> 
> 
> -
> Daniel Sun 
> Apache Groovy committer 
> Blog: http://blog.sunlan.me 
> Twitter: @daniel_sun 
> 
> --
> Sent from: http://groovy.329449.n5.nabble.com/Groovy-Users-f329450.html

Re: About the groovy code style

[Daniel.Sun]

Yep. Daniil.



-
Daniel Sun 
Apache Groovy committer 
Blog: http://blog.sunlan.me 
Twitter: @daniel_sun 

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

Re: About the groovy code style

[Daniil Ovchinnikov]

You mean me?

—

Daniil Ovchinnikov
JetBrains


> On 4 Jul 2018, at 05:39, Daniel.Sun  wrote:
> 
> ping Danil  :-)
> 
> 
> 
> -
> Daniel Sun 
> Apache Groovy committer 
> Blog: http://blog.sunlan.me 
> Twitter: @daniel_sun 
> 
> --
> Sent from: http://groovy.329449.n5.nabble.com/Groovy-Users-f329450.html

Re: About the groovy code style

[Daniel.Sun]

Hi Paul,

> def foobar2 = 'foo'
> + 'bar2'
> 
> which compiles but gives a runtime error:
> MissingMethodException: No signature of method:
> java.lang.String.positive()
> 
> 
> Since + here is the unary plus operator which while seldom used in that
> fashion is a valid operator.
> 
> Strangely, the foobar2 example parses and runs successfully on Groovy 3
> setting
> foobar2 to 'foo'. I'll have to check if that is a bug or "feature".

It is a bug of Parrot and is fixed in 3.0.0-alpha-4. See
https://github.com/apache/groovy/commit/2c1f7e3c47b3c1d12c05a1540307c43f1267b10f

Cheers,
Daniel.Sun




-
Daniel Sun 
Apache Groovy committer 
Blog: http://blog.sunlan.me 
Twitter: @daniel_sun 

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

Re: About the groovy code style

[Daniel.Sun]

ping Danil  :-)



-
Daniel Sun 
Apache Groovy committer 
Blog: http://blog.sunlan.me 
Twitter: @daniel_sun 

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

Re: About the groovy code style

[Jochen Theodorou]

Am 03.07.2018 um 04:44 schrieb Daniel.Sun:

Hi all,

  The following code is supported in the older parser, but I propose to
stop supporting the ugly code style in the new Parrot parser. Any thoughts?

1) import statement ( https://issues.apache.org/jira/browse/GROOVY-8642 )
```
import java.
lang.
Object
```

2) prefix operator ( https://issues.apache.org/jira/browse/GROOVY-8650 )
```
def c = --
1


I do not need these.. but since I know Danil is doing special things 
with DSL, maybe we should first ask him if he needs that and why


bye Jochen

Re: About the groovy code style

[Paul King]

I think it is worth reviewing some of these edge cases but we want to keep
the overall conceptual
model describing the parser behavior (i.e. parser rules) as simple as
possible.

Here is my understanding of the rules for the classic parser. Java supports
a fluent api style such as:

String lowerCity = person
.getAddress()
.getCity()
.getName()
.toLowerCase();

Java knows when to stop because of the trailing semicolon. Groovy doesn't
require the trailing
semicolon so has the following additional rules. If the tokens at the end
of a line don't make up
a complete expression, looking onto the next line is done. This accounts
for various opening and
closing delimiters but also when using '.'. This allows expressions like:

assert person.
address.
city.
name.
toLowerCase() == 'berlin'

and:

def foobar1 = 'foo' +
'bar1'
assert foobar1.size() == 7

def baz =
 'baz'
println baz

As a follow-on rule, even if a line ends with valid tokens but the
subsequent line doesn't start with
valid tokens (in particular starts with a '.') we try to join. This allows
for:

assert person
.address
.city
.name
.size() == 6

But doesn't allow for:

def foobar2 = 'foo'
+ 'bar2'

which compiles but gives a runtime error:
MissingMethodException: No signature of method: java.lang.String.positive()

Since + here is the unary plus operator which while seldom used in that
fashion is a valid operator.

Strangely, the foobar2 example parses and runs successfully on Groovy 3
setting
foobar2 to 'foo'. I'll have to check if that is a bug or "feature".

Groovy 2.5 similarly doesn't allow:

println 'foo'.with
{ s -> s.size() }

It compiles but fails to find the 'with' property on the 'foo' String. So
these are two
fully valid expressions one after the other.

Groovy 3 does allow this last case. That's a breaking change. I'll need to
double
check if that is something we have discussed previously and add it to the
3.0 breaking
changes if so.

Neither Groovy 2.5 nor 3 supports an anonymous inner class creation with the
curly brace on the subsequent line:

def bar = new Object()
{ String toString() { 'bar' } } // Method def not expected here
println bar.toString()

Anyway, given the above rules, my first inclination would be to retain
at least the GROOVY-8642 syntax and possibly GROOVY-8650.
I agree the use of those rules within an import is ugly but I see it
as consistent application of those rules.

But having said that, if we can describe an alternative set of rules
that are just as simple, we can have a slightly refined way of describing
the parser behavior for Groovy 3.0. I'd prefer not though to have
a very piece-meal set of rules where every construct needs to be
described separately.

Cheers, Paul.

On Tue, Jul 3, 2018 at 12:44 PM Daniel.Sun  wrote:

> Hi all,
>
>  The following code is supported in the older parser, but I propose to
> stop supporting the ugly code style in the new Parrot parser. Any thoughts?
>
> 1) import statement ( https://issues.apache.org/jira/browse/GROOVY-8642 )
> ```
> import java.
> lang.
> Object
> ```
>
> 2) prefix operator ( https://issues.apache.org/jira/browse/GROOVY-8650 )
> ```
> def c = --
> 1
> ```
>
> Cheers,
> Daniel.Sun
>
>
>
>
> -
> Daniel Sun
> Apache Groovy committer
> Blog: http://blog.sunlan.me
> Twitter: @daniel_sun
>
> --
> Sent from: http://groovy.329449.n5.nabble.com/Groovy-Users-f329450.html
>