forax at univ-mlv.fr
Fri Mar 12 11:02:18 UTC 2021
----- 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:
> It proposes *guarded patterns* of the form `p&&e`, as well as parenthesized
> patterns, written `(p)`.
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) ->
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.
>> 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:
>>>> : AssignmentExpression
>>> I think it should be this instead:
>>> : 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
>>> 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
More information about the amber-spec-experts