Guards redux

[Remi Forax]

----- Mail original -----
> De: "Gavin Bierman" <gavin.bierman at oracle.com>
> À: "John Rose" <john.r.rose at oracle.com>
> Cc: "amber-spec-experts" <amber-spec-experts at openjdk.java.net>
> Envoyé: Vendredi 12 Mars 2021 11:11:46
> Objet: Re: Guards redux

> Thanks everyone for the discussion. I have updated the JEP:
> 
> http://openjdk.java.net/jeps/8213076
> 
> It proposes *guarded patterns* of the form `p&&e`, as well as parenthesized
> patterns, written `(p)`.


Hi Gavin,
nice, i find this version more appealing.

In the first example that shows && as a guard, the example uses parenthesis which is my opinion should be removed
        case Triangle t && (t.calculateArea() > 100) -> 
            System.out.println("Large Triangle"); 

if i read the grammar correctly, those parenthesis around the boolean expression are unnecessary
        case Triangle t && t.calculateArea() > 100 -> 

it will be more inline with the example above in the text that is using 'when'
        case Triangle t when t.calculateArea() > 100 ->


Otherwise, in the document, the words "->-style" and ":-style" are hard to parse, i think array-style and colon-style are better terms.


In the section "Dominance of pattern label",
It's not clear to me if there is a dominance in between expressions,
by example, can we have the following cases in that order ?

  case Foo(var a, var b) && a == 3:
  case Foo(var a, var b) && a == 3 && b  == 4:

for me the answer is yes, the dominance is computed on patterns only, not on expressions.


> 
> I have left out AND and OR patterns, at least for now. Thanks to Guy we now know
> how to add them elegantly to the grammar when the time comes :-) When people
> come to play with this, I’d be especially interested to hear about the need for
> AND and OR patterns. (I have a feeling that OR is more important, but that’s
> another email...)
> 
> Comments on the JEP very welcome.
> 
> Thanks,
> Gavin

regards,
Rémi

> 
> 
>> On 11 Mar 2021, at 13:51, Gavin Bierman <gavin.bierman at oracle.com> wrote:
>> 
>> Very clever, John. Yes, let’s not add any more puzzlers to the language!
>> 
>>> On 10 Mar 2021, at 21:59, John Rose <john.r.rose at oracle.com> wrote:
>>> 
>>> Good.  PrimaryPattern is a good concept.
>>> 
>>> On Mar 10, 2021, at 6:47 AM, Gavin Bierman <gavin.bierman at oracle.com> wrote:
>>>> 
>>>> Guard:
>>>> : AssignmentExpression
>>> 
>>> I think it should be this instead:
>>> 
>>> Guard:
>>> : ConditionalAndExpression
>>> 
>>> The effects of this narrower definition of a guard expression
>>> are two:
>>> 
>>> First, any guard of the form (a || b), (a ? b : c), or (a = b)
>>> will require parentheses.
>>> 
>>> Second, as a result, the following puzzlers will not be legal
>>> inputs:
>>> 
>>> case P && a || b:  // compare x instanceof P && a || b
>>> case P && a ? b : c:  // compare x instanceof P && a ? b : c
>>> case P && a = b:  // compare x instanceof P && a = b
>>> 
>>> In all of these puzzlers, the “extremely fortuitous”
>>> correspondence between the syntaxes of guarded
>>> cases and instanceof’s with following boolean logic
>>> are broken.
>>> 
>>> The fix to align the meanings of the cases with the
>>> instanceof’s is to add parentheses:
>>> 
>>> case P && (a || b):  // compare x instanceof P && (a || b)
>>> case P && (a ? b : c):  // compare x instanceof P && (a ? b : c)
>>> case P && (a = b):  // compare x instanceof P && (a = b)
>>> 
>>> Using the modified grammar rule above forces the
>>> coder to write the parentheses, I think.
>>> 
>>> I think we should aim for “perfectly fortuitous”
>>> here, not just “well, look how often the syntaxes
>>> seem to mean the same thing although sometimes
>>> they don’t”.  Indeed, this is my main reason for
>>> plumping  for P && g in the first place.
>>> 
>>> — John
>>> 
>>>