Guards redux
Gavin Bierman
gavin.bierman at oracle.com
Fri Mar 12 10:11:46 UTC 2021
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)`.
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
> 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
>>
>>
>
More information about the amber-spec-experts
mailing list