<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<font size="4" face="monospace">Despite several years of warnings
and other attempts at preparing the ground, you seem intent on
falling into the trap of thinking that these things are "just
methods" and that we are better served by generalizing methods to
support patterns. Everything about the model here places patterns
as dual to methods; trying to hide that with syntax that makes it
look like "just a method" is then putting the ball in our own net,
because it props up wrong ideas about what is going on. <br>
<br>
(In the classfile translation, we will of course use methods, and
some sort of carrier, but that's a compilation trick, and we
surely don't want to expose this model to ordinary programmers
(though MethodHandle programmers will probably have to deal with
it.)) <br>
<br>
Unlike methods, patterns are conditional. <br>
Unlike methods, patterns can bind zero or more results. <br>
Unlike methods, patterns are overloaded on their bindings, not
their arguments. <br>
<br>
<blockquote type="cite">Now, what i call a carrier type is what
you call a list of bindings.</blockquote>
<br>
You can call it that, but the syntax you are proposing presents it
as something different -- as a thing that is returned from a
method. <br>
<br>
<blockquote type="cite">
<div>And I do not know how you define what a binding list is but
multiple return + components description is a good definition
for me.<br data-mce-bogus="1">
</div>
</blockquote>
<br>
We define it the same way as we define a parameter list. A
parameter list is not a first-class thing in the language; you
can't express one separately from a method call, or assign one to
a variable, or return one. It is strictly a linguistic mechanism
for (a) declaring the shape of a method and (b) passing parameters
to a method at runtime. <br>
<br>
A binding list is the dual of this; it is strictly a linguistic
mechanism for (a) declaring the shape of a pattern and (b) passing
bindings _from_ a pattern at runtime. <br>
<br>
<br>
<br>
<br>
<br>
</font><br>
<div class="moz-cite-prefix">On 4/3/2024 10:23 AM, <a class="moz-txt-link-abbreviated" href="mailto:forax@univ-mlv.fr">forax@univ-mlv.fr</a>
wrote:<br>
</div>
<blockquote type="cite" cite="mid:152426466.46744752.1712154202764.JavaMail.zimbra@univ-eiffel.fr">
<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" <a class="moz-txt-link-rfc2396E" href="mailto:brian.goetz@oracle.com"><brian.goetz@oracle.com></a><br>
<b>To: </b>"Remi Forax" <a class="moz-txt-link-rfc2396E" href="mailto:forax@univ-mlv.fr"><forax@univ-mlv.fr></a><br>
<b>Cc: </b>"amber-spec-experts"
<a class="moz-txt-link-rfc2396E" href="mailto:amber-spec-experts@openjdk.java.net"><amber-spec-experts@openjdk.java.net></a><br>
<b>Sent: </b>Wednesday, April 3, 2024 2:48:40 PM<br>
<b>Subject: </b>Re: Member Patterns -- the bikeshed<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" face="monospace">I would summarize your comments
below as: Let's throw the entire model in the garbage, and
replace it with something like Scala's "return an
Optional<Tuple>" instead.</font><font size="4" face="monospace"><br>
<br>
We've been discussing the model for several years; you've
been asking (and waiting patiently) for "when are we going
to talk about declaration syntax", and now that we're
there, you want to throw it all out and start over? </font></blockquote>
<div><br>
</div>
<div>My makeup job was too big so you do not recognize your
model behind :)<br data-mce-bogus="1">
</div>
<div><br data-mce-bogus="1">
</div>
<div>There are two parts, the declaration part and the
use-site part.<br data-mce-bogus="1">
</div>
<div>Correct me if i'm wrong but apart the support of a method
pattern with no prefix, we are in agreement here.<br data-mce-bogus="1">
</div>
<div><br data-mce-bogus="1">
</div>
<div>For the declaration part, I think that<br>
</div>
<div> carrier(int x, int y) asCartesian()</div>
<div>is more readable than<br data-mce-bogus="1">
</div>
<div> inverse () asCartesian(int x, int y)<br data-mce-bogus="1">
</div>
<div><br data-mce-bogus="1">
</div>
<div>The inverse notation is a leaky abstraction in a leat two
cases<br>
</div>
<div>- when a modifier or an annotation is used. For an
annotation, there is a notion of a target and the parameter
target is at the wrong place,<br data-mce-bogus="1">
</div>
<div>- when declaring a lambda, because in that case the
parameters are not inversed.<br data-mce-bogus="1">
</div>
<div><br data-mce-bogus="1">
</div>
<div>Now, what i call a carrier type is what you call a list
of bindings.<br data-mce-bogus="1">
</div>
<div>In terms of syntax, I think it is important to put a name
in front of that list of bindings, i've proposed "carrier"
so we provide a name for that feature, it's easier when
discussing about it it or google it.<br data-mce-bogus="1">
</div>
<div>That does not change the fact that a method that returns
a carrier is a special method because it requires at least a
special erasure (because overloading), and a special
reflection API,<br data-mce-bogus="1">
</div>
<div><br data-mce-bogus="1">
</div>
<div>But I hope, we will not cross the line and have to use
new opcodes in the bytecode.</div>
<div>For me, a method that returns a carrier is something that
can be desugared classical Java elements like an enum or a
record is desugared to a class.<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;"><font size="4" face="monospace"><br>
We've discussed how strategies that rely on "ask the user
to declare a record for every API point" feel clever for
about five minutes, but start to feel old quickly. </font></blockquote>
<div><br>
</div>
<div>yes, this is what you have to do actually if you simulate
the feature with Java nowadays. Not, what you should have to
do in the future.</div>
<div>And the idea is to do better, among other things, we want
to suport overloading.<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;"><font size="4" face="monospace"><br>
<br>
The "carrier" concept in your examples seems to be just
another way of reinventing multiple return -- with the
added dis-bonus of being like but not quite the same as
records. We've been pretty clear that "multiple return"
is not the design center here.</font></blockquote>
<div><br>
</div>
<div>The idea behind a carrier is to let users define their
binding list is a way that does not feel too strange, that
why I propose to add a name/keyword in front of the binding
list.<br>
</div>
<div><br data-mce-bogus="1">
</div>
<div>And I do not know how you define what a binding list is
but multiple return + components description is a good
definition for me.<br data-mce-bogus="1">
</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;"><font size="4" face="monospace"><br>
<br>
The use of ! for indicating totality is interesting,
that's worth thinking about.<br>
<br>
<br>
</font><br>
<div class="moz-cite-prefix">On 4/3/2024 6:21 AM, Remi Forax
wrote:<br>
</div>
<blockquote cite="mid:407911070.46485631.1712139695181.JavaMail.zimbra@univ-eiffel.fr">
<div>I think that by not starting from the deconstructor,
the notion of inverse methods make less sense.</div>
<div>I think that the notion of carrier / carrier type is
less disruptive that the notion of member patterns.</div>
</blockquote>
<br>
<br>
<br>
</blockquote>
</div>
</div>
</blockquote>
<br>
</body>
</html>