<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body>
    <br>
    <blockquote type="cite" cite="mid:675389563.47530211.1712237440439.JavaMail.zimbra@univ-eiffel.fr">
      <div style="font-family: arial, helvetica, sans-serif; font-size: 12pt; color: #000000">
        <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;">
            <div dir="auto" style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;">
              <div><br>
              </div>
              <div>But taking the point of view of such a user, I just
                don’t see the need to introduce a new notion of
                “carrier" to explain the set of match results (an
                ordered sequence) from a pattern, just as I don't see
                any need to introduce a new notion of “carrier" to
                explain the set of arguments (an ordered sequence) to a
                method.</div>
            </div>
          </blockquote>
          <div><br>
          </div>
          <div>For me the notion of carrier has several advantages:<br data-mce-bogus="1">
          </div>
          <div>- it is easy to explain, a carrier is like an anynous
            record or a record with a predefined name, so this an object
            like any other normal object<br data-mce-bogus="1">
          </div>
          <div>- the syntax is to close a type declaration, so the
            syntax can be extended to add '!' or '?' to signal if the
            pattern is optional or not, with the caveat that it only
            works well if we actually introduce '!' and '?' in the
            langage.<br data-mce-bogus="1">
          </div>
        </div>
      </div>
    </blockquote>
    <br>
    Yes, this is the old "it's just a method with multiple return" /
    "method that returns Optional<Tuple>" analogy.  While
    comfortable-seeming, because it builds on things the user is already
    familiar with, this analogy is flawed.  Embracing a flawed but
    familiar model might help users in the first five minutes, but it
    will damage the language forever after.  <br>
    <br>
    Calling it something new like "carrier" has the obvious disadvantage
    that it appears to be like a record, but isn't a record.  This will
    cause endless confusion.  If we instead call these "anonymous
    records", which is at least more honest (we've been through this
    flavor of the design, it felt cool at first, but started to decay
    almost instantly), you end up trying to reify the binding list in a
    way that we deliberately _don't_ reify a method parameter list.  <br>
    <br>
    Scala's "function that returns Optional<Tuple>" is a glass
    that is half full and half empty.  It relies on generous structural
    magic, and therefore does not fully live within the type system. 
    And Scala's patterns are less ambitious; they are much more
    "static", sitting at the periphery of the object model.  <br>
    <br>
    <blockquote type="cite" cite="mid:675389563.47530211.1712237440439.JavaMail.zimbra@univ-eiffel.fr">
      <div style="font-family: arial, helvetica, sans-serif; font-size: 12pt; color: #000000">
        <div data-marker="__QUOTED_TEXT__"><br>
          <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 dir="auto" style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;">
              <div><br>
              </div>
              <div>And I suggest that in a Java-based model where
                patterns are regarded as duals of methods, the same
                observations apply to sequences of match results. There
                is no need for such a sequence to be an object, or even
                to be given a special name such as “carrier”. The
                representation of such a sequence at run time is not the
                programmer’s concern, and that in turn may make it
                easier to allocate them on the stack rather than the
                heap in some situations. All I care about as a user of
                patterns is that I supply a match candidate, a pattern
                that does not fail produces an ordered sequence of match
                results, and those results are then bound, in order, to
                variables I specify at the point of pattern use.</div>
            </div>
          </blockquote>
          <div><br>
          </div>
          <div>Patterns are not dual of methods, pattern deconstructors
            are dual of methods, but this is a special case.<br data-mce-bogus="1">
          </div>
        </div>
      </div>
    </blockquote>
    <br>
    Perhaps in Remi-world, Remi-patterns are something else.  But that's
    not the feature being designed here.  <br>
    <br>
    The design center here is that patterns are the dual of
    _aggregative_ methods (methods that takes more primitive ingredients
    and produce something more abstract), like "make me a list from
    these elements", "make me a point from this x and y", or "make me a
    class for the array type whose component type is X".  They are not
    merely "methods that return multiple values", nor are they "methods
    that might fail".  The method to which they are dual need not
    actually exist (e.g., a pattern that describes a regex match need
    not have a partner which generates conformant strings, but it
    could).  <br>
    <br>
    If you disagree about the design center, you have two choices:<br>
    <br>
     - Agree to disagree, and help design the best feature within the
    planned design center<br>
     - Be honest that you are advocating to throw the design in the
    garbage, and want to replace it with something else (likely,
    something not as fully worked through), rather than merely offering
    a "tweak" to the syntax<br>
    <br>
    The bar for the latter is very, very high.  You should make your
    case directly, honestly, persuasively, and completely, and you
    should be prepared that you may still not convince people, in which
    case it is back to choice A.  <br>
    <br>
    Even if you are not successful, there is value in trying; the value
    is in forcing us to come to a clearer statement of what the design
    center is.  We will have to explain this to others, so refining this
    story is valuable.  <br>
    <br>
    <blockquote type="cite" cite="mid:675389563.47530211.1712237440439.JavaMail.zimbra@univ-eiffel.fr">
      <div style="font-family: arial, helvetica, sans-serif; font-size: 12pt; color: #000000">
        <div data-marker="__QUOTED_TEXT__">
          <div>A pattern not only have a sequence of match results, it
            can have parameters too.<br data-mce-bogus="1">
          </div>
          <div>For example, I may want to introduce an instance pattern
            asInteger() in java.lang.String that works like
            Integer.parseInt() but not match instead of throwing an
            exception if the string does not represent an integer. </div>
        </div>
      </div>
    </blockquote>
    <br>
    So, this is a good illustration of the dangers of "method-think"
    here.  There is exactly one correct, obvious name for this pattern:
    "Integer::toString".  Except that at first, to almost everyone, it
    will not seem correct and not seem obvious.  <br>
    <br>
    When all we had for designing the pair of conversions `int
    <--> String` was methods, we modeled them as arbitrarily
    distinct, unrelated methods.  Going from int -> String was easy,
    since there was an obvious way to do it and it worked for all
    integers.  Going the other way is harder, because it is partial, and
    because the language didn't offer a canonical way to reflect
    partiality, we had to invent one, and every such method did its own
    thing (maybe it returns a default; maybe it throws; etc.)  The API
    author had to make up TWO names, and we all know naming is hard. 
    Worse, the two methods toString and parseInt were not obviously
    related, which meant that they were not discoverable from each
    other.  Worse still, the arms-length relationship between them meant
    that they could easily gratuitously diverge.  <br>
    <br>
    When this is all we could do, we did it, and didn't realize there
    was something better.  But there is something better, and once you
    see it, it is so blindingly obvious that you would not think to go
    back.  <br>
    <br>
    If you name the pattern `toString`, then:<br>
    <br>
     - The two are easily discoverable from each other;<br>
     - The author will naturally align the semantics of the two, as they
    are obviously two sides of the same coin;<br>
     - Promotion of int to String (aggregation), and the recovery of
    that int from a candidate String (destructuring), look the same:<br>
    <br>
        if (aString instanceof Integer.toString(int i)) { ... }<br>
    <br>
    This evokes the Pattern Question: "could this string have come from
    Integer.toString(i) for some i, and if so, please give me an `i` for
    which this is the case." <br>
    <br>
    If you encourage people to keep thinking about parseInt as a mere
    method, they will continue to write dramatically worse APIs, which
    are harder to write, harder to use, harder to read, and result in
    gratutious asymmetries.  <br>
    <br>
    <blockquote type="cite" cite="mid:675389563.47530211.1712237440439.JavaMail.zimbra@univ-eiffel.fr">
      <div style="font-family: arial, helvetica, sans-serif; font-size: 12pt; color: #000000">
        <div data-marker="__QUOTED_TEXT__">
          <div>I may also want that pattern to decode hexadecimal <br>
          </div>
        </div>
      </div>
    </blockquote>
    <br>
    Then find the duality.  Converting from int to hex string could
    reasonably be a method called toHexString, and there's your pattern:<br>
    <br>
        if (aString instanceof Integer.toHexString(var i)) { ... }<br>
    <br>
    <blockquote type="cite">I want my pattern to also takes a radix as
      parameter. In that case, my pattern asInteger() has an int value
      as match result and has an int radix as parameter.</blockquote>
    <br>
    Here, you are saying "I want patterns with input parameters back." 
    And I agree that they were there for a reason.  I think there is a
    better way to bring back that functionality, and we can talk about
    it when we put the core feature to rest.  <br>
    <br>
    <blockquote type="cite" cite="mid:675389563.47530211.1712237440439.JavaMail.zimbra@univ-eiffel.fr">
      <div style="font-family: arial, helvetica, sans-serif; font-size: 12pt; color: #000000">
        <div data-marker="__QUOTED_TEXT__">
          <div>Using the carrier syntax, it's something like<br data-mce-bogus="1">
          </div>
        </div>
      </div>
    </blockquote>
    <br>
    Please stop pretending that this is a mere syntax choice.  This is a
    complete reinterpretation of what patterns are.  You want patterns
    to "just" be "conditional methods that can return multiple things." 
    I get how that seems a useful feature, but if that's what you want,
    then the burden is on you is to be honest about it and to convince
    us to make a radical change of direction.  The mere existence of
    "here is some useful code I could write with my direction" is barely
    even a start at that.  <br>
    <br>
    <br>
  </body>
</html>