<!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>