<html><body><div style="font-family: arial, helvetica, sans-serif; font-size: 12pt; color: #000000"><div><br></div><div><br></div><hr id="zwchr" data-marker="__DIVIDER__"><div data-marker="__HEADERS__"><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><b>From: </b>"Brian Goetz" <brian.goetz@oracle.com><br><b>To: </b>"Remi Forax" <forax@univ-mlv.fr>, "Gavin Bierman" <gavin.bierman@oracle.com><br><b>Cc: </b>"Tagir Valeev" <amaembo@gmail.com>, "amber-dev" <amber-dev@openjdk.org>, "amber-spec-experts" <amber-spec-experts@openjdk.org><br><b>Sent: </b>Tuesday, October 4, 2022 12:16:21 AM<br><b>Subject: </b>Re: Draft JEPs: Pattern Matching for switch and Record Patterns<br></blockquote></div><div data-marker="__QUOTED_TEXT__"><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><font size="4"><font face="monospace">I was skeptical at first too,
but the weight of the points Gavin raises makes me feel that
this aspect was (a) a little rushed and (b) not critical, so
backing it out now gives us a chance to think it through
further, and bring it back later in this or another form.</font></font></blockquote><div><br></div><div>I agree on (a), we need to put more work on it.<br data-mce-bogus="1"></div><div>Nothing here is critical so i suppose i agree on (b) but i would prefer to keep it because i want people to test mixing any patterns ('_') and record patterns,<br data-mce-bogus="1"></div><div>e.g.<br data-mce-bogus="1"></div><div> case Point p -> ...<br data-mce-bogus="1"></div><div>vs<br data-mce-bogus="1"></div><div> case Point(_,_) p -> ...<br data-mce-bogus="1"></div><div>vs<br data-mce-bogus="1"></div><div> case Point(int _, int _) p -> ...</div><div><br data-mce-bogus="1"></div><div>Rémi<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><br>
<br>
<div class="moz-cite-prefix">On 10/3/2022 12:25 PM, Remi Forax
wrote:<br>
</div>
<blockquote cite="mid:304331103.17970907.1664814348728.JavaMail.zimbra@u-pem.fr">
<div style="font-family: arial, helvetica, sans-serif; font-size:
12pt; color: #000000">
<div><br>
</div>
<div><br>
</div>
<hr id="zwchr">
<div>
<blockquote style="border-left:2px solid
#1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><b>From:
</b>"Gavin Bierman" <a class="moz-txt-link-rfc2396E" href="mailto:gavin.bierman@oracle.com" target="_blank"><gavin.bierman@oracle.com></a><br>
<b>To: </b>"Tagir Valeev" <a class="moz-txt-link-rfc2396E" href="mailto:amaembo@gmail.com" target="_blank"><amaembo@gmail.com></a><br>
<b>Cc: </b>"amber-dev" <a class="moz-txt-link-rfc2396E" href="mailto:amber-dev@openjdk.org" target="_blank"><amber-dev@openjdk.org></a>,
"amber-spec-experts" <a class="moz-txt-link-rfc2396E" href="mailto:amber-spec-experts@openjdk.org" target="_blank"><amber-spec-experts@openjdk.org></a><br>
<b>Sent: </b>Monday, October 3, 2022 5:29:40 PM<br>
<b>Subject: </b>Re: Draft JEPs: Pattern Matching for switch
and Record Patterns<br>
</blockquote>
</div>
<div>
<blockquote style="border-left:2px solid
#1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;">Hi
Tagir,
</blockquote>
<div><br>
</div>
<div>The main objection to remove the name of the record
pattern is that it does not follow the principle of the data
oriented programming.</div>
<div>The idea is that the data is more important than the
code, or said differently, if the data change by example a
component is added to a record, the compiler should flag all
the code that uses that record and ask the user to modify
the code.<br>
</div>
<div><br>
</div>
<div>So a case with a record pattern is better than just a
type pattern, because unlike a type pattern, a record
pattern validates the shape of a record<br>
</div>
<div> </div>
<div> case Point p // does not validate the shape of Point<br>
</div>
<div> case Point(int x, int y) p // validates that a Point
has two components x and y.</div>
<div><br>
</div>
<div>When using virtual polymorphism, an operation is defined
as an abstract method, so if the record shape changes,
people will scan the rest of the record and change the
implementation of the methods according to the new
components. If the operation uses pattern matching, the
record and the operation are not declared at the same place,
so the compiler has to help users to find all the locations
in the code that should be updated.<br>
</div>
<div><br>
</div>
<blockquote style="border-left:2px solid
#1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;">
<div class=""><br class="">
</div>
<div class="">So it was a number of issues actually. First,
there is a nasty ambiguity problem. Consider:</div>
<div class=""><br class="">
</div>
<div class=""><font class="" face="Courier">record R(){} <br class="">
switch(e) { <br class="">
case R() when when (true) -> ... <br class="">
... <br class="">
} </font><br class="">
<br class="">
The label could be parsed as either: <br class="">
<br class="">
<font class="" face="Courier"> case (R() when) when
(true) -> <br class=""></font><br class="">
or <br class="">
<br class="">
<font class="" face="Courier"> case (R()) when
(when(true)) -> <br class=""></font><br class="">
(where `<font class="" face="Courier">when</font>` is a
static boolean method). </div>
</blockquote>
<div><br>
</div>
<div>It's a usual issue with local keywords, we had the same
kind of issue with the local keywords inside modules
(transitive as a keyword or has a package name).<br>
</div>
<div><br>
</div>
<div>A solution on top of my head is to make "when" a keyword
for the whole case (everything in between "case" and
"->"), so having to consecutive "when" is not
syntactically valid.<br>
</div>
<div>It's not the only option, and i don't think it's a
showstopper.<br>
</div>
<div><br>
</div>
<blockquote style="border-left:2px solid
#1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;">
<div class=""><br class="">
<div class=""><br class="">
</div>
<div class="">There is another issue which is this
variable declaration is the only one in the language
that can’t be annotated or marked as `final` which feels
like a design smell. None of the obvious solutions to
this looked good. </div>
</div>
</blockquote>
<div><br>
</div>
<div>For me, a group pattern is not really different than a
type pattern for this concern,<br>
</div>
<div>the current syntax is with a type pattern is<br>
</div>
<div> case final Point p -><br>
</div>
<div>so the syntax for a record pattern is<br>
</div>
<div> case final Point(int x,int y) p -><br>
</div>
<div><br>
</div>
<div>It awkward and super verbose but it's a straight
consequence of not having the binding always final.<br>
</div>
<div><br>
</div>
<blockquote style="border-left:2px solid
#1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;">
<div class="">
<div class=""><br class="">
</div>
<div class="">In most other languages with pattern
matching they keep these two things - a destructing
pattern and a naming pattern - separate. In both Haskell
and Scala, they write `x@p` to “name” a pattern p as x.
So that seems like a possibility. But for now, we noted
that in most cases you can rewrite pretty simply, e.g.</div>
<div class=""><br class="">
</div>
<div class=""><font class="" face="Courier">
case Point(var x, var y) when p.isVisible() -> </font></div>
<div class=""><br class="">
</div>
<div class="">can be rewritten:</div>
<div class=""><br class="">
</div>
<div class=""><font class="" face="Courier"> case Point
p <br class="">
when p.isVisible() && p instanceof
Point(var x, var y): …<br class=""></font><br class="">
or if it was in an instanceof:<br class="">
<br class="">
<font class="" face="Courier"> if (x instanceof Point
p && p.isVisible() && p instanceof
Point(var x, var y)) { … }</font></div>
<div><br class="">
</div>
<div>Neither of these versions read too badly.</div>
</div>
</blockquote>
<div><br>
</div>
<div>I disagree, a case ... does not exist in the vacuum but
works and is read with the other cases.<br>
</div>
<div>Here, following "case Point p when ... ", you will have a
proper record pattern of Point to be exhaustive and the lack
of common prefix between the two patterns makes the code
hard to read.<br>
</div>
<div><br>
</div>
<div> Point p = ...<br>
</div>
<div> switch(p) {<br>
</div>
<div> case Point p<br>
</div>
<div> when p.isVisible() && p instanceof Point
(var x, var y) -> ...<br>
</div>
<div> case Point(int x, int y) -> ...<br>
</div>
<div> }<br>
</div>
<div><br>
</div>
<div>compared to</div>
<div>
<div> Point p = ...</div>
<div> switch(p) {</div>
<div> case Point(int x, int y) p when p.isVisible() ->
...</div>
<div> case Point(int x, int y) p -> ...</div>
<div> }</div>
<br>
</div>
<div>Here, it's clear that the first line is a peculiar case
of the second line.<br>
</div>
<div><br>
</div>
<blockquote style="border-left:2px solid
#1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;">
<div class="">
<div><br class="">
</div>
<div>Thoughts?</div>
<div><br class="">
</div>
<div>Gavin</div>
</div>
</blockquote>
<div><br>
</div>
<div>Rémi<br>
</div>
<div><br>
</div>
<div><br>
</div>
<blockquote style="border-left:2px solid
#1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;">
<div class="">
<div><br class="">
</div>
<div><br class="">
<blockquote class="">
<div class="">On 3 Oct 2022, at 14:40, Tagir Valeev
<<a href="mailto:amaembo@gmail.com" class="moz-txt-link-freetext" target="_blank">amaembo@gmail.com</a>>
wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<div class="">Hello!<br class="">
<br class="">
<blockquote class="">Remove support for named
record patterns.<br class="">
</blockquote>
<br class="">
This surprises me. Probably there was a discussion
about the rationale<br class="">
behind this change? Could you please point me?
Thanks.<br class="">
<br class="">
With best regards,<br class="">
Tagir Valeev<br class="">
<br class="">
On Mon, Oct 3, 2022 at 2:48 PM Gavin Bierman <<a href="mailto:gavin.bierman@oracle.com" class="moz-txt-link-freetext" target="_blank">gavin.bierman@oracle.com</a>>
wrote:<br class="">
<blockquote class=""><br class="">
Dear all,<br class="">
<br class="">
The draft JEPs for the next preview of the
Pattern Matching for switch and Record Patterns
features are now available at:<br class="">
<br class="">
Pattern matching for switch: <a href="https://bugs.openjdk.org/browse/JDK-8294285" class="moz-txt-link-freetext" target="_blank">
https://bugs.openjdk.org/browse/JDK-8294285</a><br class="">
Record Patterns: <a href="https://bugs.openjdk.org/browse/JDK-8294078" class="moz-txt-link-freetext" target="_blank">https://bugs.openjdk.org/browse/JDK-8294078</a><br class="">
<br class="">
Comments welcomed!<br class="">
Gavin<br class="">
</blockquote>
</div>
</div>
</blockquote>
</div>
<br class="">
</div>
<br>
</blockquote>
</div>
</div>
</blockquote>
<br><br></blockquote></div></div></body></html>