Swiss Cheese Issue - Revisit?

[Remi Forax]

> 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