You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@groovy.apache.org by "Daniel.Sun" <su...@apache.org> on 2018/10/22 18:00:54 UTC
About refining regex literal syntax
Hi all,
Groovy regex literal allows new lines, i.e. 0D0A, which introduces
some ambiguity and breaks consistency in syntax. Let's have a look at some
examples:
1) Ambiguity example:
```
m /ab
c/ d
```
This can be parsed as a command chain expression or parsed as two arithmetic
expressions.
2) Consistency breaking in syntax
Single line:
'abc'
"abc"
Multiple lines:
'''
abc
'''
"""
abc
"""
/
abc
/
$/
abc
/$
As you can see, both two version of regex literal can span multiple
lines...
I propose to forbidden new lines in one version of regex literal since
Groovy 3.0.0:
Single line:
'abc'
"abc"
/abc/
Multiple lines:
'''
abc
'''
"""
abc
"""
$/
abc
/$
Any thoughts?
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-Dev-f372993.html
Re: About refining regex literal syntax
Posted by MG <mg...@arscreat.com>.
Am 22.10.2018 um 22:34 schrieb Guillaume Laforge:
> Damn, MG will tell me again I'm reacting negatively to Daniel's ideas
> but... :-)
No, no - it's not a knee jerk reaction. In this case I see both points,
and am torn on what I would prefer...
(Generally speaking, while having a "regex string literal syntax" in
Groovy is great and I use it quite a bit, I always thought that using
the slash delmiter for this was alas not a good choice, so if breaking
changes are on the table, I would consider fading out slashy strings in
favor of a different syntax. I am also high on Jochen's suggestion to
streamline/unify the different string syntax varieties in Groovy...)
Cheers,
mg
Re: About refining regex literal syntax
Posted by Dierk König <co...@me.com>.
Changing regex syntax is a breaking change that comes without compiler warnings.
Dierk
sent from:mobile
> Am 22.10.2018 um 22:34 schrieb Guillaume Laforge <gl...@gmail.com>:
>
> Damn, MG will tell me again I'm reacting negatively to Daniel's ideas but... :-)
>
> Interestingly, the multiline support in regex was kind of a highlight of Groovy's support of regexes as they allowed making more readable regular expressions.
> If you have it, have a look at some of the examples in Groovy in Action which highlighted this.
>
> The most intuitive human parsing here is certainly (m / ab) then (c / d), and not the command chain expression, and indeed the parser currently parses it as the intuitive human approach.
>
> Command chain expressions would have been parsed though if indeed we had use the triple (single/double) quote syntax, which would also be an intuitive human parsing.
>
> Expecting the parse to be a command chain with the slashy strings would seem counter intuitive to me.
>
> So call me resistant to change if you will MG ;-) but I quite like the current behavior.
>
> Guillaume
>
>> On Mon, Oct 22, 2018 at 8:00 PM Daniel.Sun <su...@apache.org> wrote:
>> Hi all,
>>
>> Groovy regex literal allows new lines, i.e. 0D0A, which introduces
>> some ambiguity and breaks consistency in syntax. Let's have a look at some
>> examples:
>>
>> 1) Ambiguity example:
>> ```
>> m /ab
>> c/ d
>> ```
>> This can be parsed as a command chain expression or parsed as two arithmetic
>> expressions.
>>
>> 2) Consistency breaking in syntax
>> Single line:
>> 'abc'
>> "abc"
>>
>> Multiple lines:
>> '''
>> abc
>> '''
>> """
>> abc
>> """
>> /
>> abc
>> /
>> $/
>> abc
>> /$
>>
>> As you can see, both two version of regex literal can span multiple
>> lines...
>>
>> I propose to forbidden new lines in one version of regex literal since
>> Groovy 3.0.0:
>>
>> Single line:
>> 'abc'
>> "abc"
>> /abc/
>>
>> Multiple lines:
>> '''
>> abc
>> '''
>> """
>> abc
>> """
>> $/
>> abc
>> /$
>>
>> Any thoughts?
>>
>> 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-Dev-f372993.html
>
>
> --
> Guillaume Laforge
> Apache Groovy committer & PMC Vice-President
> Developer Advocate @ Google Cloud Platform
>
> Blog: http://glaforge.appspot.com/
> Twitter: @glaforge
Re: About refining regex literal syntax
Posted by Paul King <pa...@asert.com.au>.
It would be nice to simplify Strings especially in light of Raw String
literals being added to Java which I suspect we will want to support at
some stage. The thing is that slashy and dollar slashy strings aren't the
same in various ways not just line endings. Changing them to be more the
same (so that they could be considered the single and multi-line versions
of one another) would be quite a large change. Obviously Groovy 3.0 is a
time to consider larger changes than normal.
However, having just one example isn't enough for me to properly evaluate
the merits of a potential change.
I believe a full blown GEP would be required. E.g. would the proposed
change alter the meaning of the following:
m /c/ d
Which can mean any of:
m(/c/).d
(m/c)/d
m/(c/d)
Another example, slashy strings are special in that they can appear in only
certain places in the grammar, so you can't have:
println /foo/
or any empty slashy string (it's a comment):
def x = //
'foo'
assert x.size() == 3
And these are just a few of dozens of cases we should look at if really
trying to simplify string handling. We'd ideally include raw strings too.
Some of the cases for slashy string won't change since removing the
newlines won't change the underlying circumstances causing these
restrictions but we'd need to check if any do or allow us to make further
improvements if we wanted to. We would also need to cover migration tools
in the GEP since we'd be breaking lots of existing code potentially.
Cheers, Paul.
On Tue, Oct 23, 2018 at 11:02 AM Daniel Sun <re...@hotmail.com> wrote:
> Hi Guillaume,
>
> Groovy has multiline version for regex already, i.e. `$/.../$`, so
> `/.../` also supporting is redundant IMHO ;-)
>
> Similarly, `"..."` and `'...'` have their multline versions, i.e.
> `'''...'''` and `"""..."""`, so they just support single line.
>
> P.S. `"..."` and `'...'` support multiline in Parrot, it is
> actually
> a bug and fixed last week.
>
> Cheers,
> Daniel.Sun
>
>
>
> --
> Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
>
Re: About refining regex literal syntax
Posted by "Daniel.Sun" <su...@apache.org>.
Hi Jochen,
If the string is invalid, lexer can detect the error efficiently.
In addition, editing one line version of string will not impact
lexer to recognize the remaining source code, which is very important for
the performance of source code highlighter.
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-Dev-f372993.html
Re: About refining regex literal syntax
Posted by Jochen Theodorou <bl...@gmx.org>.
On 23.10.2018 03:01, Daniel Sun wrote:
> Hi Guillaume,
>
> Groovy has multiline version for regex already, i.e. `$/.../$`, so
> `/.../` also supporting is redundant IMHO ;-)
>
> Similarly, `"..."` and `'...'` have their multline versions, i.e.
> `'''...'''` and `"""..."""`, so they just support single line.
>
> P.S. `"..."` and `'...'` support multiline in Parrot, it is actually
> a bug and fixed last week.
Is there actually a technical need to limit the " and ` version to be
single line?
bye Jochen
Re: About refining regex literal syntax
Posted by Daniel Sun <re...@hotmail.com>.
Hi Guillaume,
Groovy has multiline version for regex already, i.e. `$/.../$`, so
`/.../` also supporting is redundant IMHO ;-)
Similarly, `"..."` and `'...'` have their multline versions, i.e.
`'''...'''` and `"""..."""`, so they just support single line.
P.S. `"..."` and `'...'` support multiline in Parrot, it is actually
a bug and fixed last week.
Cheers,
Daniel.Sun
--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
Re: About refining regex literal syntax
Posted by Guillaume Laforge <gl...@gmail.com>.
Damn, MG will tell me again I'm reacting negatively to Daniel's ideas
but... :-)
Interestingly, the multiline support in regex was kind of a highlight of
Groovy's support of regexes as they allowed making more readable regular
expressions.
If you have it, have a look at some of the examples in Groovy in Action
which highlighted this.
The most intuitive human parsing here is certainly (m / ab) then (c / d),
and not the command chain expression, and indeed the parser currently
parses it as the intuitive human approach.
Command chain expressions would have been parsed though if indeed we had
use the triple (single/double) quote syntax, which would also be an
intuitive human parsing.
Expecting the parse to be a command chain with the slashy strings would
seem counter intuitive to me.
So call me resistant to change if you will MG ;-) but I quite like the
current behavior.
Guillaume
On Mon, Oct 22, 2018 at 8:00 PM Daniel.Sun <su...@apache.org> wrote:
> Hi all,
>
> Groovy regex literal allows new lines, i.e. 0D0A, which introduces
> some ambiguity and breaks consistency in syntax. Let's have a look at some
> examples:
>
> 1) Ambiguity example:
> ```
> m /ab
> c/ d
> ```
> This can be parsed as a command chain expression or parsed as two
> arithmetic
> expressions.
>
> 2) Consistency breaking in syntax
> Single line:
> 'abc'
> "abc"
>
> Multiple lines:
> '''
> abc
> '''
> """
> abc
> """
> /
> abc
> /
> $/
> abc
> /$
>
> As you can see, both two version of regex literal can span multiple
> lines...
>
> I propose to forbidden new lines in one version of regex literal
> since
> Groovy 3.0.0:
>
> Single line:
> 'abc'
> "abc"
> /abc/
>
> Multiple lines:
> '''
> abc
> '''
> """
> abc
> """
> $/
> abc
> /$
>
> Any thoughts?
>
> 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-Dev-f372993.html
>
--
Guillaume Laforge
Apache Groovy committer & PMC Vice-President
Developer Advocate @ Google Cloud Platform
Blog: http://glaforge.appspot.com/
Twitter: @glaforge <http://twitter.com/glaforge>