Stupid question: What is barring supporting
final r = switch(a) {
case 6: yield 'a'
default: yield 'b'
}
i.e. without any brackets/new operators ? The bracket construct cannot
be a closure, since switch is a keyword, so would it be ambiguous... ?
Related: I have seen
More concise syntax should be feasible too(statement in parentheses), e.g.
```
def a = 6
def r = (
switch (a) {
case 6: yield 'a'
default: yield 'b'
}
)
assert 'a' == r
```
Cheers,
Daniel.Sun
-
Apache Groovy committer & PMC member
Blog: http://blog.s
Hi Jochen,
> Do we really? If we really want to support it, we should support its
> use-case, which is a Lexer. Writing an efficient lexer in Groovy would
> be way off with switch expressions, because of the transformation to
> Closure and the overhead it involves.
To be frank, I'm not sure if we
On 05.11.19 08:39, Daniel.Sun wrote:
Hi Rémi,
Thanks for your detailed explaining. Switch expression is useful in
some cases, but fallthrough is error prone. I seldom use switch statement,
in the past, I widely used it when I wrote lexer/parser by hand. I prefer to
use if-else instead, whi
Hi Rémi,
Thanks for your detailed explaining. Switch expression is useful in
some cases, but fallthrough is error prone. I seldom use switch statement,
in the past, I widely used it when I wrote lexer/parser by hand. I prefer to
use if-else instead, which is much more powerful.
Though
ttern matching switches so in term of
percents the number of switches used on strings + fallthrough will be
negligible.
Rémi
- Mail original -
> De: "Daniel.Sun"
> À: "dev"
> Envoyé: Mardi 5 Novembre 2019 05:21:16
> Objet: Re: [VOTE] Support switch expressi
It does not matter. Different people have different concerns.
Maybe we could do better if time allowed:
https://blog.joda.org/2019/11/java-switch-4-wrongs-dont-make-right.html
> and Happy Birthday from me, whenever the exact date is G-)
Thank you, MG :-)
Cheers,
Daniel.Sun
-
Apache Gro
PS: Sorry to criticize, Daniel. Your efforts for Groovy are much
appreciated - and Happy Birthday from me, whenever the exact date is G-)
On 04/11/2019 20:43, Daniel.Sun wrote:
This is just a reference implementation, we can tweak it over time.
Now that you have a prototype in hand for conver
Hi guys,
wondering if Groovy's macro functionality could help here ?
While I see Daniel's point about the brevity/elegance of his
implementation, I am wondering whether a low level language construct
like switch-case should be modelled by a (non-inlined) closure, due to
1) the overhead involv
This is just a reference implementation, we can tweak it over time.
> Now that you have a prototype in hand for conversion to ClosureExpression
> with nested SwitchStatement, would it be a good idea to at least try the
> SwitchExpression route to see how much effort difference is involved?
As Céd
A couple notes:
1) Eclipse chose to implement switch expression as a separate AST type from
switch statement. This provides explicit separation of different parsing and
other semantics. Also in Groovy 3, method references were implemented as a new
AST type instead of converting to MethodPoint
Fix typo:
2nd transformed code in the parser to eliminate the shared variables before
instruction selection phase
->
2nd transformed code to eliminate the shared
variables before instruction selection phase
Cheers,
Daniel.Sun
-
Apache Groovy committer & PMC member
I have 2 ideas in my mind:
1) Implement switch expression from scratch, in other words, we need parse
code into a brand new`SwitchExpression` in AST, then implement flowing type
because we have static groovy, at last generate bytecode. -- need quite a
few work, but it should be able to very clos
he options considered and the
choices made, you are requiring the voters to redo this thought process or
accept your choices on faith.
From: Daniel.Sun
Sent: Monday, November 4, 2019 10:49 AM
To: d...@groovy.incubator.apache.org
Subject: Re: [VOTE] Support switch
You know code block is not an expression. The reason to transform switch
expression to switch statement in closure is make switch expression appear
everywhere, e.g.
```
def process(String s) { "Hello, $s" }
def a = 6
def r = process(
switch (a) {
case 6 -> 'a'
default
6:
case 8: r ='x'; break
case 9: r = 'y'; break
default: r = 'z'; break
}
}
```
From: Milles, Eric (TR Tech, Content & Ops)
Sent: Monday, November 4, 2019 9:56 AM
To: d...@groovy.incubator.apache.org
By re-writing the AST as a closure expression you are going to add closure
semantics to all the variables referenced within the switch. There are a
number of differences between variables in a block and variables within a
closure.
Is there any idea of how close Java is to finalizing their synt
17 matches
Mail list logo
