You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@groovy.apache.org by Jesper Steen Møller <je...@selskabet.org> on 2018/03/01 15:39:42 UTC
[GEP] Switch expressions syntax from Java 11 or 12 (perhaps)
Hi list
Java 11 (or perhaps 12) might see a new functionality known as switch expressions (https://bugs.openjdk.java.net/browse/JDK-8192963 <https://bugs.openjdk.java.net/browse/JDK-8192963>).
While the current Groovy implicit return functionality works with the switch statement as-is, the switch expression is a more general construct, basically it is to the conditional operator (a ? b : c) what the switch statement is to if/then/else-if/else. An example:
int numLetters = switch (day) {
case MONDAY, FRIDAY, SUNDAY -> 6;
case TUESDAY -> 7;
case THURSDAY, SATURDAY -> 8;
case WEDNESDAY -> 9;
};
with
case LABEL -> expression;
essentially sugar for
case LABEL: break expression;
As I see it: It could add utility to the Groovy language, and adopting it would keep up the the Java-compatibility gap, which I think is a valuable gateway-drug to discovering the joys of Groovy. The "break <expression> syntax isn't pretty, but the arrows look fine and incur no syntax compatibility problem, as far as I can see.
Now, this being Groovy, the cases should surely support the extended "isCase"-support, as described so well here: http://mrhaki.blogspot.dk/2009/08/groovy-goodness-switch-statement.html <http://mrhaki.blogspot.dk/2009/08/groovy-goodness-switch-statement.html>
So, three questions remain:
1) Useful or not?
2) This Java compatibility - is it still a thing? I remember a similar proposal a little while back, but this would align better with Java.
3) This could be implemented using existing AST's if we really want to, but it would be clumsy. This AST transformer compatibility - is it still a thing?
-Jesper
Re: [GEP] Switch expressions syntax from Java 11 or 12 (perhaps)
Posted by Jochen Theodorou <bl...@gmx.org>.
On 08.03.2018 20:52, Remi Forax wrote:
[...]
> using break here is ugly, i agree with you but we (the amber EG) are not able to find a better solution,
> if you know a better way to handle local return of a value in the case of a switch, please help us.
should inspiration strike me I will let you guys know ;)
[...]
> no, the Java part of the pattern matching is mostly decided (there is still corner cases like how re-starting when a guard fails).
> The pattern matching is delayed more because
> 1/ the VM support is not there, part will be in the jdk 11, but how to specify a sealed interface to avoid to have to specify a default when you have cover all the cases is still open.
> 2/ the support of de-constructor (extractor) to keep encapsulation without allocation in the middle of the pattern matching requires:
> 2a/ value types, good progress have been made on the valhalla side, a release of value types without changing generics (which is a major PITA) may be a temporary solution.
> 2b/ another temporary solution is to make pattern matching only working on records (data classes).
>
> The only part of the pattern matching which is ugly IMO is how to specify a "local return" of a value in a case with several instructions.
I really do not want to sound like a broken record, but I really think
the local return problem is no problem with the lambda version. Its
limitations are already accepted there. Of course it is unfair to jump
in with a comment like that, without taking the time to see what was
worked out and why before.
As for the deconstructor... yes I was really curious about how that
problem is going to be solved.
> Now, releasing an expression switch first has several advantages:
> - allow to align the old switch with the pattern matching switch by modernizing the behavior of the old switch with respect to null.
+1
> - it fixes several bugs of the current switch implementation:
> - having to recompile the switch when you change the enum
> - the switch on string being slow when the number of cases is small
> - reduce the switch footprint in term of bytecodes
sounds good, but I have to see how useful this is outside the intended
use for pattern matching. It is for example unlikely to replace our most
annoying switch-case usage in Groovy internally, which is to select the
right "super" and "this" delegation call in a constructor
> - and obviously allow to use a switch that "returns" an expression.
I don't think I would like to think of it as returning an expression ;)
In total I am not fully convinced that a lambda usage is bad here. But
then again maybe I am more willing to live with some trade-offs coming
from that approach than the EG is. It is just...
* reusing syntax elements and give it new semantics is bad
* introducing new syntax elements should be avoided
Those are principles I go with in language design. Sure,you can not
always keep that,so it is to be weighted with the gain, but the
switch-expressions seem to have quite the initial momentum to overcome
to show its value like that.
bye Jochen
Re: [GEP] Switch expressions syntax from Java 11 or 12 (perhaps)
Posted by Jochen Theodorou <bl...@gmx.org>.
On 09.03.2018 21:48, forax@univ-mlv.fr wrote:
[...]
> but in a switch, you can not delay the creation of a case (technically you can because you can always do weird thing but, it's not what people will expect),
> so disallowing
> int i = 0;
> switch(foo) {
> case 0 -> { i++; }
> }
> make little sense.
but what you would do is not that, it is:
> int i = 0;
> i += switch(foo) {
> case 0 -> 1 > default -> 0;
> }
which also means to be forced to move to a more functional style. Maybe
you can show more examples?
bye Jochen
Re: [GEP] Switch expressions syntax from Java 11 or 12 (perhaps)
Posted by fo...@univ-mlv.fr.
----- Mail original -----
> De: "MG" <mg...@arscreat.com>
> À: "dev" <de...@groovy.apache.org>, "Remi Forax" <fo...@univ-mlv.fr>
> Envoyé: Jeudi 8 Mars 2018 23:55:11
> Objet: Re: [GEP] Switch expressions syntax from Java 11 or 12 (perhaps)
> Hi Remi,
>
> I have used Groovy exclusively for the last years, so not really used to
> Java lambdas, but why can't you use something along the line of:
>
> int result = switch (s) {
> case "Foo" -> 1;
> case "Bar" -> 2;
> case default -> (System.out.println("Neither Foo nor Bar,
> hmmm..."); 3; )
> }
>
> or
>
> int result = switch (s) {
> case "Foo" -> 1;
> case "Bar" -> 2;
> case PATTERN_ANY -> { System.out.println("Neither Foo nor Bar,
> hmmm..."); 3; }
> }
>
> etc ?
in a lambda in Java, you can not modify a local variable declared outside of the lambda,
by example
int i = 0;
Runnable r = () -> { i++; };
does not compile.
The idea behind is the compiler needs to expand the liveness of 'i' to be accessible outside the code that declare 'i' and this is only allowed if 'i' do not change its value.
This restriction is important because it means the JIT can create the lambda whenever it wants and not necessarily when the user declare it (note: the JIT already does that for any other expressions that why we wanted to keep that capability).
but in a switch, you can not delay the creation of a case (technically you can because you can always do weird thing but, it's not what people will expect),
so disallowing
int i = 0;
switch(foo) {
case 0 -> { i++; }
}
make little sense.
>
> I am in the "never liked break camp", so I also would not want to see
> its use elevated... ;-)
i agree, that's the wrong message.
> Cheers,
> mg
regards,
Rémi
>
>
> On 08.03.2018 20:52, Remi Forax wrote:
>>
>>>> int result = switch (s) {
>>>> case "Foo" -> 1;
>>>> case "Bar" -> 2;
>>>> default:
>>>> System.out.println("Neither Foo nor Bar, hmmm...");
>>>> break 3;
>>>> }
>>> is straight from the JEP 325 page. And that was actually my point, this
>>> overlap, but redefinition of break.
>> yes, you can not use the normal break/containue inside an expression,
>> so break foo; in an expression switch has only one meaning.
>>
>>> break is what makes the switch-case ugly for most people in the first place.
>>> Giving that special treatment like this looks off to me.
>> using break here is ugly, i agree with you but we (the amber EG) are not able to
>> find a better solution,
>> if you know a better way to handle local return of a value in the case of a
>> switch, please help us.
>>
Re: [GEP] Switch expressions syntax from Java 11 or 12 (perhaps)
Posted by MG <mg...@arscreat.com>.
Hi Remi,
I have used Groovy exclusively for the last years, so not really used to
Java lambdas, but why can't you use something along the line of:
int result = switch (s) {
case "Foo" -> 1;
case "Bar" -> 2;
case default -> (System.out.println("Neither Foo nor Bar,
hmmm..."); 3; )
}
or
int result = switch (s) {
case "Foo" -> 1;
case "Bar" -> 2;
case PATTERN_ANY -> { System.out.println("Neither Foo nor Bar,
hmmm..."); 3; }
}
etc ?
I am in the "never liked break camp", so I also would not want to see
its use elevated... ;-)
Cheers,
mg
On 08.03.2018 20:52, Remi Forax wrote:
>
>>> int result = switch (s) {
>>> case "Foo" -> 1;
>>> case "Bar" -> 2;
>>> default:
>>> System.out.println("Neither Foo nor Bar, hmmm...");
>>> break 3;
>>> }
>> is straight from the JEP 325 page. And that was actually my point, this
>> overlap, but redefinition of break.
> yes, you can not use the normal break/containue inside an expression,
> so break foo; in an expression switch has only one meaning.
>
>> break is what makes the switch-case ugly for most people in the first place. Giving that special treatment like this looks off to me.
> using break here is ugly, i agree with you but we (the amber EG) are not able to find a better solution,
> if you know a better way to handle local return of a value in the case of a switch, please help us.
>
>
Re: [GEP] Switch expressions syntax from Java 11 or 12 (perhaps)
Posted by Remi Forax <fo...@univ-mlv.fr>.
----- Mail original -----
> De: "Jochen Theodorou" <bl...@gmx.org>
> À: "dev" <de...@groovy.apache.org>
> Envoyé: Jeudi 8 Mars 2018 19:51:57
> Objet: Re: [GEP] Switch expressions syntax from Java 11 or 12 (perhaps)
> On 08.03.2018 17:34, Remi Forax wrote:
> [...]
>>>> int accumulator = 0
>>>> LOOP: for (T element : someList) {
>>>> accumulator += switch (element.type) {
>>>> case PLUS_ONE -> +1;
>>>> case MINUS_ONE -> -1;
>>>> case ERROR:
>>>> break LOOP;
>>>> case default -> 0
>>>> }
>>>> }
>>>
>>> with the idea that element.type is an enum... But my problem is with
>>> break LOOP. Is LOOP the label LOOP, or is it a constant/variable?
>>
>> this will not compile, because you can not use return or break/continue inside
>> an expression switch.
>
> you mean I cannot use the normal break/continue inside an expression
> switch, because this example
>
>> int result = switch (s) {
>> case "Foo" -> 1;
>> case "Bar" -> 2;
>> default:
>> System.out.println("Neither Foo nor Bar, hmmm...");
>> break 3;
>> }
>
> is straight from the JEP 325 page. And that was actually my point, this
> overlap, but redefinition of break.
yes, you can not use the normal break/containue inside an expression,
so break foo; in an expression switch has only one meaning.
> break is what makes the switch-case ugly for most people in the first place. Giving that special treatment like this looks off to me.
using break here is ugly, i agree with you but we (the amber EG) are not able to find a better solution,
if you know a better way to handle local return of a value in the case of a switch, please help us.
>
>>> If they need the break only to break out of the switch, then why not
>>> capitalize on lambdas ?
>>
>> it was the first idea :)
>> but lambda can capture effectively final local variable, when a case in an
>> expression switch acts more like a routine so you can access any variables with
>> no restriction. So re-using the same syntax for two different semantics is not
>> a good idea.
>
> A problem you would not have in Groovy, because we don´t do the
> capturing like Java.
It's not like in java but you use a box so the perf model is still not the same between a captured variable and a plain old variable in Groovy.
>
>> The idea is that the expression switch should be used when it's a simple switch
>> and the C switch with all it's subtle behaviors if the control flow is more
>> complex,
>> exactly like you use for(:) if it's a simple loop and for(;;) if it's a more
>> complex one.
>
> maybe, but I still think it does not make so much sense on its own. With
> a step-by-step approach of getting features in I can understand this,
> but then it means to decide to use this here, before deciding the
> details of pattern matching... and that sounds wrong.
no, the Java part of the pattern matching is mostly decided (there is still corner cases like how re-starting when a guard fails).
The pattern matching is delayed more because
1/ the VM support is not there, part will be in the jdk 11, but how to specify a sealed interface to avoid to have to specify a default when you have cover all the cases is still open.
2/ the support of de-constructor (extractor) to keep encapsulation without allocation in the middle of the pattern matching requires:
2a/ value types, good progress have been made on the valhalla side, a release of value types without changing generics (which is a major PITA) may be a temporary solution.
2b/ another temporary solution is to make pattern matching only working on records (data classes).
The only part of the pattern matching which is ugly IMO is how to specify a "local return" of a value in a case with several instructions.
Now, releasing an expression switch first has several advantages:
- allow to align the old switch with the pattern matching switch by modernizing the behavior of the old switch with respect to null.
- it fixes several bugs of the current switch implementation:
- having to recompile the switch when you change the enum
- the switch on string being slow when the number of cases is small
- reduce the switch footprint in term of bytecodes
- and obviously allow to use a switch that "returns" an expression.
>
> bye Jochen
regards,
Rémi
Re: [GEP] Switch expressions syntax from Java 11 or 12 (perhaps)
Posted by Jochen Theodorou <bl...@gmx.org>.
On 08.03.2018 17:34, Remi Forax wrote:
[...]
>>> int accumulator = 0
>>> LOOP: for (T element : someList) {
>>> accumulator += switch (element.type) {
>>> case PLUS_ONE -> +1;
>>> case MINUS_ONE -> -1;
>>> case ERROR:
>>> break LOOP;
>>> case default -> 0
>>> }
>>> }
>>
>> with the idea that element.type is an enum... But my problem is with
>> break LOOP. Is LOOP the label LOOP, or is it a constant/variable?
>
> this will not compile, because you can not use return or break/continue inside an expression switch.
you mean I cannot use the normal break/continue inside an expression
switch, because this example
> int result = switch (s) {
> case "Foo" -> 1;
> case "Bar" -> 2;
> default:
> System.out.println("Neither Foo nor Bar, hmmm...");
> break 3;
> }
is straight from the JEP 325 page. And that was actually my point, this
overlap, but redefinition of break. break is what makes the switch-case
ugly for most people in the first place. Giving that special treatment
like this looks off to me.
>> If they need the break only to break out of the switch, then why not
>> capitalize on lambdas ?
>
> it was the first idea :)
> but lambda can capture effectively final local variable, when a case in an expression switch acts more like a routine so you can access any variables with no restriction. So re-using the same syntax for two different semantics is not a good idea.
A problem you would not have in Groovy, because we don´t do the
capturing like Java.
> The idea is that the expression switch should be used when it's a simple switch and the C switch with all it's subtle behaviors if the control flow is more complex,
> exactly like you use for(:) if it's a simple loop and for(;;) if it's a more complex one.
maybe, but I still think it does not make so much sense on its own. With
a step-by-step approach of getting features in I can understand this,
but then it means to decide to use this here, before deciding the
details of pattern matching... and that sounds wrong
bye Jochen
Re: [GEP] Switch expressions syntax from Java 11 or 12 (perhaps)
Posted by Remi Forax <fo...@univ-mlv.fr>.
Hi Jochen,
----- Mail original -----
> De: "Jochen Theodorou" <bl...@gmx.org>
> À: "dev" <de...@groovy.apache.org>
> Envoyé: Vendredi 2 Mars 2018 00:57:16
> Objet: Re: [GEP] Switch expressions syntax from Java 11 or 12 (perhaps)
> On 01.03.2018 16:39, Jesper Steen Møller wrote:
> [...]
>> |int numLetters = switch (day) { case MONDAY, FRIDAY, SUNDAY -> 6; case
>> TUESDAY -> 7; case THURSDAY, SATURDAY -> 8; case WEDNESDAY -> 9; };|
>>
>> with
>>
>> |case LABEL -> expression;|
>>
>> essentially sugar for
>>
>> |case LABEL: break expression;|
>
> to make this straight.
>
>> int result = switch (s) {
>> case "Foo":
>> break 1;
>> case "Bar":
>> break 2;
>> default:
>> System.out.println("Neither Foo nor Bar, hmmm...");
>> break 3;
>> }
>
> is the long form of
>
>> int result = switch (s) {
>> case "Foo" -> 1;
>> case "Bar" -> 2;
>> default:
>> System.out.println("Neither Foo nor Bar, hmmm...");
>> break 3;
>> }
>
> The default here has no shorter version, because they are using a
> statement and need to return something in the expression. I understood
> the proposal, that both forms are valid and can be mixed.
>
> There is a few things I dislike...and most of all it is the break
> command here.
>
>> int accumulator = 0
>> LOOP: for (T element : someList) {
>> accumulator += switch (element.type) {
>> case PLUS_ONE -> +1;
>> case MINUS_ONE -> -1;
>> case ERROR:
>> break LOOP;
>> case default -> 0
>> }
>> }
>
> with the idea that element.type is an enum... But my problem is with
> break LOOP. Is LOOP the label LOOP, or is it a constant/variable?
this will not compile, because you can not use return or break/continue inside an expression switch.
>
> If they need the break only to break out of the switch, then why not
> capitalize on lambdas ?
it was the first idea :)
but lambda can capture effectively final local variable, when a case in an expression switch acts more like a routine so you can access any variables with no restriction. So re-using the same syntax for two different semantics is not a good idea.
The idea is that the expression switch should be used when it's a simple switch and the C switch with all it's subtle behaviors if the control flow is more complex,
exactly like you use for(:) if it's a simple loop and for(;;) if it's a more complex one.
[...]
>
> bye Jochen
cheers,
Rémi
Re: [GEP] Switch expressions syntax from Java 11 or 12 (perhaps)
Posted by Jochen Theodorou <bl...@gmx.org>.
On 01.03.2018 16:39, Jesper Steen Møller wrote:
[...]
> |int numLetters = switch (day) { case MONDAY, FRIDAY, SUNDAY -> 6; case
> TUESDAY -> 7; case THURSDAY, SATURDAY -> 8; case WEDNESDAY -> 9; };|
>
> with
>
> |case LABEL -> expression;|
>
> essentially sugar for
>
> |case LABEL: break expression;|
to make this straight.
> int result = switch (s) {
> case "Foo":
> break 1;
> case "Bar":
> break 2;
> default:
> System.out.println("Neither Foo nor Bar, hmmm...");
> break 3;
> }
is the long form of
> int result = switch (s) {
> case "Foo" -> 1;
> case "Bar" -> 2;
> default:
> System.out.println("Neither Foo nor Bar, hmmm...");
> break 3;
> }
The default here has no shorter version, because they are using a
statement and need to return something in the expression. I understood
the proposal, that both forms are valid and can be mixed.
There is a few things I dislike...and most of all it is the break
command here.
> int accumulator = 0
> LOOP: for (T element : someList) {
> accumulator += switch (element.type) {
> case PLUS_ONE -> +1;
> case MINUS_ONE -> -1;
> case ERROR:
> break LOOP;
> case default -> 0
> }
> }
with the idea that element.type is an enum... But my problem is with
break LOOP. Is LOOP the label LOOP, or is it a constant/variable?
If they need the break only to break out of the switch, then why not
capitalize on lambdas?
> int accumulator = 0
> LOOP: for (T element : someList) {
> accumulator += switch (element.type) {
> case PLUS_ONE -> +1;
> case MINUS_ONE -> -1;
> case ERROR -> {break LOOP;}
> case default -> 0
> }
> }
This would be much more aligned with what Java has, then you would
naturally use return if you are required to use statements. Plus it
would align more with what is in JEP-305 with for example "case Integer
i -> i+1". I would not even support the column version for a switch
expression.
And then of course there is the basic problem: you have to have a single
expression. Not many people are actually like using switch-case, I do,
but rarely this is for me in the break expression style as described.
For me this whole construct makes no sense without JEP-305 and for that
JEP you do not need some of the variants described at all. Let us not
forget that the switch-object is limited to quasi constants such as
strings, enum values and integers. They do not have the isCase
construct, thus no variant to do an equals based check. Even with
JEP-305, this is not changed. In theory you could do something like this
in Java:
> accumulator += switch-case (element.type,
> new Case(PLUS_ONE, -> +1),
> new Case(MINUS_ONE, -> -1),
> new Case(-> 0));
Then switch-case can be a generic function, that checks the Case objects
for the supplied matched and on equality executed the provided lambda.
This variant would realize the break expression version and would not
support labels or return statements (only as part of the lambda). But it
would be possible to do, even extensible to do more than just that - and
allow lambdas for the matcher as well.
[...]> Now, this being Groovy, the cases should surely support the extended
> "isCase"-support, as described so well here:
> http://mrhaki.blogspot.dk/2009/08/groovy-goodness-switch-statement.html
>
> So, three questions remain:
> 1) Useful or not?
for me not, it is one of the constructs I would not use. And given the
sentiment against switch-case by many programmers, they would not either.
> 2) This Java compatibility - is it still a thing? I remember a similar
> proposal a little while back, but this would align better with Java.
IMHO there is still work in that bug report to align better with Java ;)
For Groovy yes... if they add it to Java, we add it to Groovy... but not
because it is good or useful, just for compatibility
> 3) This could be implemented using existing AST's if we /_really_/ want
> to, but it would be clumsy. This AST transformer compatibility - is it
> still a thing?
Sure it is a thing, but I doubt it can be implemented using the AST.
switch-case is a statement, and while we have expression-statements
(expressions as statements) we do not have statements as expressions.
And I think none of the constructs in the bug would even pass the
parser. Without parser, no AST.
Meaning to implement this, you have to change the grammar,then you have
to introduce a new expression type and extend the visitors to support
it. And finally you may be able to match it to the switch statement, but:
int f(n, m) {
int res = switch (n) {
case 0 -> m+1;
default -> switch(m) {
case 0 -> f(n-1,1)
default -> f(n-1, f(n,m-1))
}
}
return res;
}
This will not be easy, because you will need a temporary variable if you
want to simulate this with the statement form... And frankly not sure it
is worth it compared to a "real" implementation in the compiler, which
will not have to use it. Of course you would normally not use
switch-case for this, it is just an example for a complex expression
having a nested switch-case-expression.
In summary: I would wait for what the Java guys decide in the end.
bye Jochen
Re: [GEP] Switch expressions syntax from Java 11 or 12 (perhaps)
Posted by MG <mg...@arscreat.com>.
+1 on Java compatibility, otherwise not a big fan of switch statments, I
have always found the syntax inelegant and the appliaction domain too
limited.
But it looks like with pattern matching and without the need to use
break it could finally become less of a Mauerblümchen-statement for me...
I use the similar
final result = eval {
// local variables
if(...) { return ... }
else if(...) { return ... }
...
}
static def eval(Closure cls) { cls() }
programming pattern on a regular basis*
it is one of the many reasons why adding support for inlining code to
Groovy would make a lot of sense to me. In this case where the closure
argument to the static eval-method is definitely only used once,
replacing the closure with an inlined block construct would be the
superior solution here. This poses the general question how much one
could achieve in Groovy in a generic/flexible manner, if constructs like
inlined closures would be added to the language... ?
*Note: Introducing a small helper method instead of the eval-construct
can of course be the better solution, if one does not have to pass too
many parameters to said method, and if one is not hard pressed to find a
meaningful name for it...
On 01.03.2018 17:44, Paolo Di Tommaso wrote:
> I agree that groovy should continue to be compatible with java syntax
> as long as possible.
>
>
> Cheers,
> Paolo
>
>
> On Thu, Mar 1, 2018 at 5:28 PM, Guillaume Laforge <glaforge@gmail.com
> <ma...@gmail.com>> wrote:
>
> 1) Very useful :-)
> 2) I think we should continue the compatibility with Java, like
> we're doing for Groovy 3, and add that syntax when it's finalized.
> 3) It's too early to think about the implementation, let's wait
> till the syntax is crystalized first!
>
> But yeah, I like the idea of supporting it.
> (and we could potentially support it before the Java version
> containing it is released)
>
> Guillaume
>
>
> On Thu, Mar 1, 2018 at 4:39 PM, Jesper Steen Møller
> <jesper@selskabet.org <ma...@selskabet.org>> wrote:
>
> Hi list
>
> Java 11 (or perhaps 12) might see a new functionality known as
> switch expressions
> (https://bugs.openjdk.java.net/browse/JDK-8192963
> <https://bugs.openjdk.java.net/browse/JDK-8192963>).
>
> While the current Groovy implicit return functionality works
> with the switch statement as-is, the switch/expression/ is a
> more general construct, basically it is to the conditional
> operator (a ? b : c) what the switch /statement/ is to
> if/then/else-if/else. An example:
>
> |int numLetters = switch (day) { case MONDAY, FRIDAY, SUNDAY ->
> 6; case TUESDAY -> 7; case THURSDAY, SATURDAY -> 8; case
> WEDNESDAY -> 9; };|
>
> with
>
> |case LABEL -> expression;|
>
> essentially sugar for
>
> |case LABEL: break expression;|
>
> As I see it: It could add utility to the Groovy language, and
> adopting it would keep up the the Java-compatibility gap,
> which I think is a valuable gateway-drug to discovering the
> joys of Groovy. The "break <expression> syntax isn't pretty,
> but the arrows look fine and incur no syntax compatibility
> problem, as far as I can see.
>
> Now, this being Groovy, the cases should surely support the
> extended "isCase"-support, as described so well here:
> http://mrhaki.blogspot.dk/2009/08/groovy-goodness-switch-statement.html
> <http://mrhaki.blogspot.dk/2009/08/groovy-goodness-switch-statement.html>
>
> So, three questions remain:
> 1) Useful or not?
> 2) This Java compatibility - is it still a thing? I remember a
> similar proposal a little while back, but this would align
> better with Java.
> 3) This could be implemented using existing AST's if we
> /_really_/ want to, but it would be clumsy. This AST
> transformer compatibility - is it still a thing?
>
> -Jesper
>
>
>
>
>
>
> --
> Guillaume Laforge
> Apache Groovy committer & PMC Vice-President
> Developer Advocate @ Google Cloud Platform
>
> Blog: http://glaforge.appspot.com/ <http://glaforge.appspot.com/>
> Social: @glaforge <http://twitter.com/glaforge> / Google+
> <https://plus.google.com/u/0/114130972232398734985/posts>
>
>
Re: [GEP] Switch expressions syntax from Java 11 or 12 (perhaps)
Posted by Jesper Steen Møller <je...@selskabet.org>.
I'm very aware of that (there's a link, too, at the bottom of the JIRA), but from a syntax point of view, they've managed to keep things orthogonal, as I see it. We should rush things, and be sure to match the grammar obviously, surely, but I don't see how one would really block the other.
In Groovy, we'd have the same ambiguity in the 'case'-labels as with commands now, but I'm sure we could work with that (upper-case implies type name). For the switch expression vs. switch statement ambiguity, I'm sure we could fix that, by choosing the statement form if there is ambiguity.
-Jesper
> On 1 Mar 2018, at 18.34, Cédric Champeau <ce...@gmail.com> wrote:
>
> You have to be aware that this java syntax prepares the way for pattern matching. I think we need to wait and see before doing it.
>
> Le 1 mars 2018 17:45, "Paolo Di Tommaso" <paolo.ditommaso@gmail.com <ma...@gmail.com>> a écrit :
> I agree that groovy should continue to be compatible with java syntax as long as possible.
>
>
> Cheers,
> Paolo
>
>
> On Thu, Mar 1, 2018 at 5:28 PM, Guillaume Laforge <glaforge@gmail.com <ma...@gmail.com>> wrote:
> 1) Very useful :-)
> 2) I think we should continue the compatibility with Java, like we're doing for Groovy 3, and add that syntax when it's finalized.
> 3) It's too early to think about the implementation, let's wait till the syntax is crystalized first!
>
> But yeah, I like the idea of supporting it.
> (and we could potentially support it before the Java version containing it is released)
>
> Guillaume
>
>
> On Thu, Mar 1, 2018 at 4:39 PM, Jesper Steen Møller <jesper@selskabet.org <ma...@selskabet.org>> wrote:
> Hi list
>
> Java 11 (or perhaps 12) might see a new functionality known as switch expressions (https://bugs.openjdk.java.net/browse/JDK-8192963 <https://bugs.openjdk.java.net/browse/JDK-8192963>).
>
> While the current Groovy implicit return functionality works with the switch statement as-is, the switch expression is a more general construct, basically it is to the conditional operator (a ? b : c) what the switch statement is to if/then/else-if/else. An example:
>
> int numLetters = switch (day) {
> case MONDAY, FRIDAY, SUNDAY -> 6;
> case TUESDAY -> 7;
> case THURSDAY, SATURDAY -> 8;
> case WEDNESDAY -> 9;
> };
> with
> case LABEL -> expression;
> essentially sugar for
> case LABEL: break expression;
> As I see it: It could add utility to the Groovy language, and adopting it would keep up the the Java-compatibility gap, which I think is a valuable gateway-drug to discovering the joys of Groovy. The "break <expression> syntax isn't pretty, but the arrows look fine and incur no syntax compatibility problem, as far as I can see.
>
> Now, this being Groovy, the cases should surely support the extended "isCase"-support, as described so well here: http://mrhaki.blogspot.dk/2009/08/groovy-goodness-switch-statement.html <http://mrhaki.blogspot.dk/2009/08/groovy-goodness-switch-statement.html>
>
> So, three questions remain:
> 1) Useful or not?
> 2) This Java compatibility - is it still a thing? I remember a similar proposal a little while back, but this would align better with Java.
> 3) This could be implemented using existing AST's if we really want to, but it would be clumsy. This AST transformer compatibility - is it still a thing?
>
> -Jesper
>
>
>
>
>
>
> --
> Guillaume Laforge
> Apache Groovy committer & PMC Vice-President
> Developer Advocate @ Google Cloud Platform
>
> Blog: http://glaforge.appspot.com/ <http://glaforge.appspot.com/>
> Social: @glaforge <http://twitter.com/glaforge> / Google+ <https://plus.google.com/u/0/114130972232398734985/posts>
Re: [GEP] Switch expressions syntax from Java 11 or 12 (perhaps)
Posted by Jesper Steen Møller <je...@selskabet.org>.
Hi MG
> On 1 Mar 2018, at 20.56, MG <mg...@arscreat.com> wrote:
>
> You mean http://cr.openjdk.java.net/~briangoetz/amber/pattern-match.html <http://cr.openjdk.java.net/~briangoetz/amber/pattern-match.html> ?
>
It's been split up into JEP 325 (switch expr) and http://openjdk.java.net/jeps/305 <http://openjdk.java.net/jeps/305> (pattern matching, relies on JEP 325). I'm pretty sure your link has intentional "stawman"-grammar, that's been refined into the proposal in JEP305.
-Jesper
Re: [GEP] Switch expressions syntax from Java 11 or 12 (perhaps)
Posted by MG <mg...@arscreat.com>.
You mean http://cr.openjdk.java.net/~briangoetz/amber/pattern-match.html ?
On 01.03.2018 18:34, Cédric Champeau wrote:
> You have to be aware that this java syntax prepares the way for
> pattern matching. I think we need to wait and see before doing it.
>
> Le 1 mars 2018 17:45, "Paolo Di Tommaso" <paolo.ditommaso@gmail.com
> <ma...@gmail.com>> a écrit :
>
> I agree that groovy should continue to be compatible with java
> syntax as long as possible.
>
>
> Cheers,
> Paolo
>
>
> On Thu, Mar 1, 2018 at 5:28 PM, Guillaume Laforge
> <glaforge@gmail.com <ma...@gmail.com>> wrote:
>
> 1) Very useful :-)
> 2) I think we should continue the compatibility with Java,
> like we're doing for Groovy 3, and add that syntax when it's
> finalized.
> 3) It's too early to think about the implementation, let's
> wait till the syntax is crystalized first!
>
> But yeah, I like the idea of supporting it.
> (and we could potentially support it before the Java version
> containing it is released)
>
> Guillaume
>
>
> On Thu, Mar 1, 2018 at 4:39 PM, Jesper Steen Møller
> <jesper@selskabet.org <ma...@selskabet.org>> wrote:
>
> Hi list
>
> Java 11 (or perhaps 12) might see a new functionality
> known as switch expressions
> (https://bugs.openjdk.java.net/browse/JDK-8192963
> <https://bugs.openjdk.java.net/browse/JDK-8192963>).
>
> While the current Groovy implicit return functionality
> works with the switch statement as-is, the
> switch/expression/ is a more general construct, basically
> it is to the conditional operator (a ? b : c) what the
> switch /statement/ is to if/then/else-if/else. An example:
>
> |int numLetters = switch (day) { case MONDAY, FRIDAY,
> SUNDAY -> 6; case TUESDAY -> 7; case THURSDAY, SATURDAY ->
> 8; case WEDNESDAY -> 9; };|
>
> with
>
> |case LABEL -> expression;|
>
> essentially sugar for
>
> |case LABEL: break expression;|
>
> As I see it: It could add utility to the Groovy language,
> and adopting it would keep up the the Java-compatibility
> gap, which I think is a valuable gateway-drug to
> discovering the joys of Groovy. The "break <expression>
> syntax isn't pretty, but the arrows look fine and incur no
> syntax compatibility problem, as far as I can see.
>
> Now, this being Groovy, the cases should surely support
> the extended "isCase"-support, as described so well here:
> http://mrhaki.blogspot.dk/2009/08/groovy-goodness-switch-statement.html
> <http://mrhaki.blogspot.dk/2009/08/groovy-goodness-switch-statement.html>
>
> So, three questions remain:
> 1) Useful or not?
> 2) This Java compatibility - is it still a thing? I
> remember a similar proposal a little while back, but this
> would align better with Java.
> 3) This could be implemented using existing AST's if we
> /_really_/ want to, but it would be clumsy. This AST
> transformer compatibility - is it still a thing?
>
> -Jesper
>
>
>
>
>
>
> --
> Guillaume Laforge
> Apache Groovy committer & PMC Vice-President
> Developer Advocate @ Google Cloud Platform
>
> Blog: http://glaforge.appspot.com/ <http://glaforge.appspot.com/>
> Social: @glaforge <http://twitter.com/glaforge> / Google+
> <https://plus.google.com/u/0/114130972232398734985/posts>
>
>
Re: [GEP] Switch expressions syntax from Java 11 or 12 (perhaps)
Posted by Cédric Champeau <ce...@gmail.com>.
You have to be aware that this java syntax prepares the way for pattern
matching. I think we need to wait and see before doing it.
Le 1 mars 2018 17:45, "Paolo Di Tommaso" <pa...@gmail.com> a
écrit :
> I agree that groovy should continue to be compatible with java syntax as
> long as possible.
>
>
> Cheers,
> Paolo
>
>
> On Thu, Mar 1, 2018 at 5:28 PM, Guillaume Laforge <gl...@gmail.com>
> wrote:
>
>> 1) Very useful :-)
>> 2) I think we should continue the compatibility with Java, like we're
>> doing for Groovy 3, and add that syntax when it's finalized.
>> 3) It's too early to think about the implementation, let's wait till the
>> syntax is crystalized first!
>>
>> But yeah, I like the idea of supporting it.
>> (and we could potentially support it before the Java version containing
>> it is released)
>>
>> Guillaume
>>
>>
>> On Thu, Mar 1, 2018 at 4:39 PM, Jesper Steen Møller <jesper@selskabet.org
>> > wrote:
>>
>>> Hi list
>>>
>>> Java 11 (or perhaps 12) might see a new functionality known as switch
>>> expressions (https://bugs.openjdk.java.net/browse/JDK-8192963).
>>>
>>> While the current Groovy implicit return functionality works with the
>>> switch statement as-is, the switch* expression* is a more general
>>> construct, basically it is to the conditional operator (a ? b : c) what the
>>> switch *statement* is to if/then/else-if/else. An example:
>>>
>>> int numLetters = switch (day) {
>>> case MONDAY, FRIDAY, SUNDAY -> 6;
>>> case TUESDAY -> 7;
>>> case THURSDAY, SATURDAY -> 8;
>>> case WEDNESDAY -> 9;
>>> };
>>>
>>> with
>>>
>>> case LABEL -> expression;
>>>
>>> essentially sugar for
>>>
>>> case LABEL: break expression;
>>>
>>> As I see it: It could add utility to the Groovy language, and adopting
>>> it would keep up the the Java-compatibility gap, which I think is a
>>> valuable gateway-drug to discovering the joys of Groovy. The "break
>>> <expression> syntax isn't pretty, but the arrows look fine and incur no
>>> syntax compatibility problem, as far as I can see.
>>>
>>> Now, this being Groovy, the cases should surely support the extended
>>> "isCase"-support, as described so well here:
>>> http://mrhaki.blogspot.dk/2009/08/groovy-goodness-switch-statement.html
>>>
>>> So, three questions remain:
>>> 1) Useful or not?
>>> 2) This Java compatibility - is it still a thing? I remember a similar
>>> proposal a little while back, but this would align better with Java.
>>> 3) This could be implemented using existing AST's if we *really* want
>>> to, but it would be clumsy. This AST transformer compatibility - is it
>>> still a thing?
>>>
>>> -Jesper
>>>
>>>
>>>
>>>
>>
>>
>> --
>> Guillaume Laforge
>> Apache Groovy committer & PMC Vice-President
>> Developer Advocate @ Google Cloud Platform
>>
>> Blog: http://glaforge.appspot.com/
>> Social: @glaforge <http://twitter.com/glaforge> / Google+
>> <https://plus.google.com/u/0/114130972232398734985/posts>
>>
>
>
Re: [GEP] Switch expressions syntax from Java 11 or 12 (perhaps)
Posted by Paolo Di Tommaso <pa...@gmail.com>.
I agree that groovy should continue to be compatible with java syntax as
long as possible.
Cheers,
Paolo
On Thu, Mar 1, 2018 at 5:28 PM, Guillaume Laforge <gl...@gmail.com>
wrote:
> 1) Very useful :-)
> 2) I think we should continue the compatibility with Java, like we're
> doing for Groovy 3, and add that syntax when it's finalized.
> 3) It's too early to think about the implementation, let's wait till the
> syntax is crystalized first!
>
> But yeah, I like the idea of supporting it.
> (and we could potentially support it before the Java version containing it
> is released)
>
> Guillaume
>
>
> On Thu, Mar 1, 2018 at 4:39 PM, Jesper Steen Møller <je...@selskabet.org>
> wrote:
>
>> Hi list
>>
>> Java 11 (or perhaps 12) might see a new functionality known as switch
>> expressions (https://bugs.openjdk.java.net/browse/JDK-8192963).
>>
>> While the current Groovy implicit return functionality works with the
>> switch statement as-is, the switch* expression* is a more general
>> construct, basically it is to the conditional operator (a ? b : c) what the
>> switch *statement* is to if/then/else-if/else. An example:
>>
>> int numLetters = switch (day) {
>> case MONDAY, FRIDAY, SUNDAY -> 6;
>> case TUESDAY -> 7;
>> case THURSDAY, SATURDAY -> 8;
>> case WEDNESDAY -> 9;
>> };
>>
>> with
>>
>> case LABEL -> expression;
>>
>> essentially sugar for
>>
>> case LABEL: break expression;
>>
>> As I see it: It could add utility to the Groovy language, and adopting it
>> would keep up the the Java-compatibility gap, which I think is a valuable
>> gateway-drug to discovering the joys of Groovy. The "break <expression>
>> syntax isn't pretty, but the arrows look fine and incur no syntax
>> compatibility problem, as far as I can see.
>>
>> Now, this being Groovy, the cases should surely support the extended
>> "isCase"-support, as described so well here:
>> http://mrhaki.blogspot.dk/2009/08/groovy-goodness-switch-statement.html
>>
>> So, three questions remain:
>> 1) Useful or not?
>> 2) This Java compatibility - is it still a thing? I remember a similar
>> proposal a little while back, but this would align better with Java.
>> 3) This could be implemented using existing AST's if we *really* want
>> to, but it would be clumsy. This AST transformer compatibility - is it
>> still a thing?
>>
>> -Jesper
>>
>>
>>
>>
>
>
> --
> Guillaume Laforge
> Apache Groovy committer & PMC Vice-President
> Developer Advocate @ Google Cloud Platform
>
> Blog: http://glaforge.appspot.com/
> Social: @glaforge <http://twitter.com/glaforge> / Google+
> <https://plus.google.com/u/0/114130972232398734985/posts>
>
Re: [GEP] Switch expressions syntax from Java 11 or 12 (perhaps)
Posted by Guillaume Laforge <gl...@gmail.com>.
1) Very useful :-)
2) I think we should continue the compatibility with Java, like we're doing
for Groovy 3, and add that syntax when it's finalized.
3) It's too early to think about the implementation, let's wait till the
syntax is crystalized first!
But yeah, I like the idea of supporting it.
(and we could potentially support it before the Java version containing it
is released)
Guillaume
On Thu, Mar 1, 2018 at 4:39 PM, Jesper Steen Møller <je...@selskabet.org>
wrote:
> Hi list
>
> Java 11 (or perhaps 12) might see a new functionality known as switch
> expressions (https://bugs.openjdk.java.net/browse/JDK-8192963).
>
> While the current Groovy implicit return functionality works with the
> switch statement as-is, the switch* expression* is a more general
> construct, basically it is to the conditional operator (a ? b : c) what the
> switch *statement* is to if/then/else-if/else. An example:
>
> int numLetters = switch (day) {
> case MONDAY, FRIDAY, SUNDAY -> 6;
> case TUESDAY -> 7;
> case THURSDAY, SATURDAY -> 8;
> case WEDNESDAY -> 9;
> };
>
> with
>
> case LABEL -> expression;
>
> essentially sugar for
>
> case LABEL: break expression;
>
> As I see it: It could add utility to the Groovy language, and adopting it
> would keep up the the Java-compatibility gap, which I think is a valuable
> gateway-drug to discovering the joys of Groovy. The "break <expression>
> syntax isn't pretty, but the arrows look fine and incur no syntax
> compatibility problem, as far as I can see.
>
> Now, this being Groovy, the cases should surely support the extended
> "isCase"-support, as described so well here: http://mrhaki.blogspot.dk/
> 2009/08/groovy-goodness-switch-statement.html
>
> So, three questions remain:
> 1) Useful or not?
> 2) This Java compatibility - is it still a thing? I remember a similar
> proposal a little while back, but this would align better with Java.
> 3) This could be implemented using existing AST's if we *really* want to,
> but it would be clumsy. This AST transformer compatibility - is it still a
> thing?
>
> -Jesper
>
>
>
>
--
Guillaume Laforge
Apache Groovy committer & PMC Vice-President
Developer Advocate @ Google Cloud Platform
Blog: http://glaforge.appspot.com/
Social: @glaforge <http://twitter.com/glaforge> / Google+
<https://plus.google.com/u/0/114130972232398734985/posts>