Re: expression switch vs. procedural switch

[John Rose]

On Mar 14, 2018, at 11:32 AM, Doug Lea  wrote:
> 
> looking forward to
> beating my own record using expression switches even if they
> (rarely) need weird breaky constructions

That pushed a button:

"Don't play that song, that achy breaky song..."

https://en.wikipedia.org/wiki/Achy_Breaky_Song 

Re: expression switch vs. procedural switch

[Doug Lea]

In case anyone is curious, I've been following this without much
to add to discussion:  Ever since seeing Brian's initial
proposal (which basically remains intact),  I haven't thought
of or seen anything better. I think already I hold the record for
density of SSA-like constructions in Java, and am looking forward to
beating my own record using expression switches even if they
(rarely) need weird breaky constructions.

-Doug

Re: expression switch vs. procedural switch

[forax]

> De: "Guy Steele" <guy.ste...@oracle.com>
> À: "Remi Forax" <fo...@univ-mlv.fr>
> Cc: "Kevin Bourrillion" <kev...@google.com>, "amber-spec-experts"
> <amber-spec-experts@openjdk.java.net>
> Envoyé: Mercredi 14 Mars 2018 17:12:34
> Objet: Re: expression switch vs. procedural switch

>> On Mar 14, 2018, at 12:16 PM, Remi Forax < [ mailto:fo...@univ-mlv.fr |
>> fo...@univ-mlv.fr ] > wrote:

>>> De: "Kevin Bourrillion" < [ mailto:kev...@google.com | kev...@google.com ] >
>>> À: "amber-spec-experts" < [ mailto:amber-spec-experts@openjdk.java.net |
>>> amber-spec-experts@openjdk.java.net ] >
>>> Envoyé: Mercredi 14 Mars 2018 16:55:24
>>> Objet: Re: expression switch vs. procedural switch

>>> On Tue, Mar 13, 2018 at 1:02 PM, Kevin Bourrillion < [ 
>>> mailto:kev...@google.com
>>> | kev...@google.com ] > wrote:

>>>> The more I have thought about it, the more I believe that 95% of the entire
>>>> value of expression switch is that it isn't procedural switch , and is 
>>>> easier
>>>> to reason about than procedural switch because of all things it can't do:

>>>> * can't miss cases
>>>> * can't return
>>>> * can't break/continue a containing construct
>>>> * can't fall through
>>>> * (for constants or other disjoint patterns) can't depend on the order 
>>>> of cases.

>>>> As far as I can tell, its limitations are exactly what make it useful.

>>> Brian reminded me in the other thread that as long as we voluntarily stick 
>>> to
>>> `->` style for all cases, we get all of this. So, from my perspective, if we
>>> just adopt a style rule for Google Style that when using switch in an
>>> expression context one should stick to `->`, I might have basically what I
>>> want.

>> yes, but it's what i detest the most about C++, everyone has its own dialect.

> What is the solution? A style requirement that every programmer use every
> feature in the language at least once in any program? (I have known 
> programmers
> like that, and their code was not necessarily any easier to read.)

Do not introduce a feature in the language which is used once every year is a 
good start. 
Do not add a solution to solve the corner^2 case (the corner case of a corner 
case as Brian call it) in the language. 

> I am sympathetic to your feeling about this, but have no idea how to encourage
> it or enforce it. You really can’t prevent a programmer, or group of
> programmers, from sticking to a subset that makes them happy.

on the Human aspect of programming, publish an official language guideline and 
provides tools that enforce it like Google does with Java or golang (with 
go-fmt). 

> —Guy
Rémi 

Re: expression switch vs. procedural switch

[John Rose]

On Mar 13, 2018, at 2:57 PM, Remi Forax  wrote:
> 
> it's perhaps me, but i think that Kevin saying that he wants to discourage 
> side effects, not disable them, avoiding side effects like it.next() is not 
> possible in Java.
> 
> We already have this kind of discussion when we have discussed about lambdas, 
> lambdas allow side effects but it's discouraged to use lambdas for that.
> And We already have agree that case expressions do not need to capture 
> variables, so expression in a case are like expressions in a ?:, you can do 
> side effect in them but it's discouraged.

I get that.  I'm just pointing out that, though "functional" is a great
code style heuristic, expressions which occur inside of imperative
loops will have to get themselves dirty as they work with loop
control variables.  Since imperative loops aren't going away in
the foreseeable future, we have to envision side effects inside
expressions.

This BTW is another similarity between s-switches and e-switches:
They both have a legitimate need to put side effects into local variables.
With s-switches, it is the *only* way to export a value.
With e-switches, *one* value can be exported the nice way via ->.
But with *both* switches it will be common (as it is common now)
to export *multiple* side effects (or one value and one side effect).
My proof point of this is the ubiquity of the pattern a[i++], which
delivers both a value and a side effect.

More detail:  Sometimes I write switches which export two or more
values:

String s;
int n;
switch (tag) {
case 0: s = ""; n = -1; break;
case 1: s = "one"; n = 0; break;
default:  s = "many"; n = 1; break;
}

As an extension to my point about a[i++], I would expect the freedom
to refactor that as:

String s;
int n = switch (tag) {
case 0: s = ""; break -1;
case 1: s = "one"; break 0;
default:  s = "many"; break 1;
}

There is a flexible set of variations of this multiple-value delivery.
The effect into s as a blank variable could just as easily have
been s += "one", where s has a previous value; that's closer
to the i++ in a[i++].

You will say "yuck", so do I.  The e-switch refactoring above arguably
reduces the yuck level from the s-switch.  And there are probably pretty
variations waiting to be written, if we allow them.

— John

P.S. For thoughts on value-types as cursors, see:
  http://cr.openjdk.java.net/~jrose/values/iterator-vs-cursor.html