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.
(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.))
Unlike methods, patterns are conditional.
Unlike methods, patterns can bind zero or more results.
Unlike methods, patterns are overloaded on their bindings, not their
arguments.
Now, what i call a carrier type is what you call a list of bindings.
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.
And I do not know how you define what a binding list is but multiple
return + components description is a good definition for me.
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.
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.
On 4/3/2024 10:23 AM, fo...@univ-mlv.fr wrote:
------------------------------------------------------------------------
*From: *"Brian Goetz" <brian.go...@oracle.com>
*To: *"Remi Forax" <fo...@univ-mlv.fr>
*Cc: *"amber-spec-experts" <amber-spec-expe...@openjdk.java.net>
*Sent: *Wednesday, April 3, 2024 2:48:40 PM
*Subject: *Re: Member Patterns -- the bikeshed
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.
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?
My makeup job was too big so you do not recognize your model behind :)
There are two parts, the declaration part and the use-site part.
Correct me if i'm wrong but apart the support of a method pattern with
no prefix, we are in agreement here.
For the declaration part, I think that
carrier(int x, int y) asCartesian()
is more readable than
inverse () asCartesian(int x, int y)
The inverse notation is a leaky abstraction in a leat two cases
- 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,
- when declaring a lambda, because in that case the parameters are not
inversed.
Now, what i call a carrier type is what you call a list of bindings.
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.
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,
But I hope, we will not cross the line and have to use new opcodes in
the bytecode.
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.
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.
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.
And the idea is to do better, among other things, we want to suport
overloading.
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.
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.
And I do not know how you define what a binding list is but multiple
return + components description is a good definition for me.
Rémi
The use of ! for indicating totality is interesting, that's worth
thinking about.
On 4/3/2024 6:21 AM, Remi Forax wrote:
I think that by not starting from the deconstructor, the
notion of inverse methods make less sense.
I think that the notion of carrier / carrier type is less
disruptive that the notion of member patterns.
