Swiss Cheese Issue - Revisit?

Wed May 6 17:29:58 UTC 2020

Hi Manoj, 
by "field" you mean only fields or everything in the scope with the same name, like capturable local variable with the same name. 

Rémi 

> De: "Manoj Palat" <manoj.palat at in.ibm.com>
> À: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "amber-spec-experts" <amber-spec-experts at openjdk.java.net>, "Brian Goetz"
> <brian.goetz at oracle.com>
> Envoyé: Mercredi 6 Mai 2020 18:06:20
> Objet: RE: Swiss Cheese Issue - Revisit?

> Hi Brian,
> Our proposal was " disallowing a pattern variable to shadow a field." - I don't
> see that this approach was tried from your mail.
> Was this tried - Is there any problem which you see with this approach?
> Regards,
> Manoj

>> ----- Original message -----
>> From: Remi Forax <forax at univ-mlv.fr>
>> Sent by: "amber-spec-experts" <amber-spec-experts-bounces at openjdk.java.net>
>> To: Brian Goetz <brian.goetz at oracle.com>
>> Cc: amber-spec-experts <amber-spec-experts at openjdk.java.net>
>> Subject: [EXTERNAL] Re: Swiss Cheese Issue - Revisit?
>> Date: Wed, May 6, 2020 9:07 PM

>>> De: "Remi Forax" <forax at univ-mlv.fr>
>>> À: "Brian Goetz" <brian.goetz at oracle.com>
>>> Cc: "amber-spec-experts" <amber-spec-experts at openjdk.java.net>
>>> Envoyé: Mercredi 6 Mai 2020 17:08:33
>>> Objet: Re: Swiss Cheese Issue - Revisit?
>>>> De: "Brian Goetz" <brian.goetz at oracle.com>
>>>> À: "Remi Forax" <forax at univ-mlv.fr>
>>>> Cc: "Manoj Palat" <manoj.palat at in.ibm.com>, "amber-spec-experts"
>>>> <amber-spec-experts at openjdk.java.net>
>>>> Envoyé: Mercredi 6 Mai 2020 16:41:33
>>>> Objet: Re: Swiss Cheese Issue - Revisit?
>>>> I think I get what you are saying, but we didn't go out of our way to _support_
>>>> it, we chose _not_ to go out of our way to _disallow_ it. So it's not like we
>>>> added a feature, as much as didn't disable an interaction.

>>>> Could you clarify what you mean?
>>> The pattern variable can be supported only in expression, we made an extra step
>>> to support it in the statement block following the expression, to extend the
>>> instanceof so the pattern variable go out of the scope the expression to the a
>>> part of the scope of an 'if' or 'while'.

>> my fear is that in the end, when we have pattern matching, "if instanceof" will
>> always be seen as a poor's man pattern matching, which it is, so nobody will
>> use it so extending "if instanceof" makes little sense.
>> Rémi

>>> Rémi

>>>> On 5/6/2020 10:21 AM, Remi Forax wrote:

>>>>> I would like to add that the Swiss Cheese problem is specific to instanceof,
>>>>> it's not a pattern matching issue per se.
>>>>> So there is another far easier solution to the Swiss Cheese problem, don't
>>>>> support it because instanceof will be less prominent in the future and
>>>>> instanceof in equals() can be re-written to avoid the Swiss Cheese.
>>>>> I'm afraid we have gone a step too far by trying to support it.
>>>>> Rémi

>>>>>> De: "Brian Goetz" [ mailto:brian.goetz at oracle.com | <brian.goetz at oracle.com> ]
>>>>>> À: "Manoj Palat" [ mailto:manoj.palat at in.ibm.com | <manoj.palat at in.ibm.com> ] ,
>>>>>> "amber-spec-experts" [ mailto:amber-spec-experts at openjdk.java.net |
>>>>>> <amber-spec-experts at openjdk.java.net> ]
>>>>>> Envoyé: Mercredi 6 Mai 2020 15:02:13
>>>>>> Objet: Re: Swiss Cheese Issue - Revisit?
>>>>>> We experimented with a "cheese shield" approach:

>>>>>> - compute the scope(s) of a binding variable as a set of position ranges:
>>>>>> s0..e0, s1..e1, ...
>>>>>> - compute the maximal scope for each variable: min(s0, s1, ...) .. max(e0, e1,
>>>>>> ...)
>>>>>> - treat the gaps as implicitly shadowing fields of the same name with an
>>>>>> erroneous local

>>>>>> If implementing the flow scoping is hard, I would think implementing the
>>>>>> shielded flow scoping is harder. The reason is that, while we might think that
>>>>>> there is a "natural rectangular scope" for a binding, there really isn't. So
>>>>>> the shield gives you _two_ kinds of irregularly-scoped things.

>>>>>> But, design decisions should put the user first. So the question is, whether the
>>>>>> users are served better by:

>>>>>> - having fragmented scopes, through which light can shine, or
>>>>>> - patching the holes so you cannot access the fields without qualification, even
>>>>>> though the corresponding binding variable is "out of scope"

>>>>>> And, it was really not clear which was the lesser of evils here. There was some
>>>>>> concern raised that this seemed scarier than it really is because it is "new
>>>>>> and different", but not intrinsically bad.

>>>>>> On 5/6/2020 5:28 AM, Manoj Palat wrote:

>>>>>>> Hi Brian, Gavin, all,

>>>>>>> Referring to Tagir’s example in [1]

>>>>>>> if (obj instanceof String str) {

>>>>>>> System.out.println(str.toLowerCase()); // str refers to

>>>>>>> pattern binding

>>>>>>> } else {

>>>>>>> System.out.println(str.toLowerCase()); // str refers to the field

>>>>>>> }

>>>>>>> which is mentioned as Swiss cheese issue in the replies to [1]

>>>>>>> From our development efforts in ecj (Eclipse Compiler for Java) for this
>>>>>>> feature:
>>>>>>> "swiss cheese" is hard for implementation by compiler(atleast ecj) and
>>>>>>> understanding by users alike. For conflicts *within a local scope* tools and
>>>>>>> users can use a structural strategy to find the nearest candidate declaration
>>>>>>> to which any name reference should resolve, deferring to flow analysis only the
>>>>>>> question, whether that resolution is legal. This is not true for fields, where
>>>>>>> no structural 'proximity' applies.

>>>>>>> For that reason we propose a compromise, whereby "swiss cheese" is allowed for
>>>>>>> pattern variables, but disallowed for fields shining through in the holes of
>>>>>>> the cheese. This can be achieved by disallowing a pattern variable to shadow a
>>>>>>> field. This is a significantly smaller cost than having to invent cascades of
>>>>>>> names for a cascade of pattern variables (the original motivation for swiss
>>>>>>> cheese – as in Gavin’s message[2]).

>>>>>>> With this proposals users have a chance to find a declaration by looking only up
>>>>>>> and out starting from the point of reference. For the implementation in ecj
>>>>>>> this makes a huge difference, because admitting swiss cheese involving fields
>>>>>>> would require us to abandon the strict separation of compilation phases
>>>>>>> 'resolve' and 'flow analysis'. Since this separation is one of the fundamental
>>>>>>> design principles in the ecj compiler, a change would require a major
>>>>>>> re-architecting of the compiler, draining resources from other, high priority
>>>>>>> tasks.

>>>>>>> In summary, we don't object to using flow criteria to determine whether or not a
>>>>>>> variable is in scope, we only object to flow criteria to *select* between
>>>>>>> different same-named variables, that could be in scope at the same location. As
>>>>>>> far as we can see, this situation is specific to fields and hence a change
>>>>>>> specific to fields should avoid the major complexity.

>>>>>>> In a spec, one could optionally generalize in a way that a pattern variable may
>>>>>>> never shadow any other variable (local or field) that is in scope.
>>>>>>> [1 [
>>>>>>> http://mail.openjdk.java.net/pipermail/amber-spec-experts/2019-November/001835.html
>>>>>>> |
>>>>>>> http://mail.openjdk.java.net/pipermail/amber-spec-experts/2019-November/001835.html
>>>>>>> ]
>>>>>>> [2] [
>>>>>>> https://mail.openjdk.java.net/pipermail/amber-spec-experts/2019-December/001837.html
>>>>>>> |
>>>>>>> https://mail.openjdk.java.net/pipermail/amber-spec-experts/2019-December/001837.html
>>>>>>> ]
>>>>>>> Regards,
>>>>>>> Manoj
>>>>>>> Eclipse Java Dev