<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<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? <br>
<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. <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. <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 type="cite" 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>
</body>
</html>