Re: “Deriving” functionality for classes and pattern matching on LHS of assignment?

[Brian Goetz]

On 12/5/2024 4:34 AM, vab2048 wrote:
> Hi Amber team,
>
> I was wondering about the future of two different features and thought I would just ask the mailing list.
>
> The first feature: deriving instances.
>
> Haskell allows type declarations to derive instances for certain type classes (Eq, Ord, Enum, Bounded, Show, and Read).
>
> Is it possible to get some sort of equivalent for java classes which would allow us to specify to the compiler to auto derive some code. I am thinking about easily auto-generating a toString, equals, hash code etc? We already have a form of this for records, and so bringing it to classes would make a logical next step.

The strict equivalent of this is records: in Haskell, you don't get any 
control over how to derive type classes such as Eq and Show, and 
similarly for records: the one the compiler gives uses all the state.  
So in some sense, mission accomplished.  But that's not really what 
you're asking.  What you're asking is for an _arbitrary class_ -- not 
just a `data` type -- to be able to get these somehow.

We did several extensive explorations of various options, but they all 
fail at the same root: that unless you declare your class in a special 
way where where these things all use all the state components (which is 
how records do it), the user will surely have some opinion about which 
field values feed into the derivation (and possibly how -- e.g., are 
arrays handled by identity or by content?)  And not all deriviations 
will want to use the same set of field values.  (And OMG what about 
mutability.  And for accessors, what about name selection?  Etc etc.)  
When you sketch it out, you end up with something that is basically a 
syntax generator with about the same (enormous) programming model 
surface as typical "bean" generators -- which is to say, a mess, and a 
mess for which no solution will be complete enough.  (Our mantra for 
records was that zero was the only acceptable number of "knobs", because 
once there is one knob, there are arbitrarily many.)

So while it may sound like a "logical next step", the complexity goes up 
by orders of magnitude, and you lose the best thing about records at the 
same time -- that record-ness is a semantic, not syntactic, construct.  
So I am skeptical about that step.

> The second feature: pattern matching on LHS of assignment.
>
> Suppose we have this record type:
>
> record Color(byte red, byte green, byte blue) {}
>
> and a static factory method “someFactory” which returns a Color.
>
> Are there any plans to allow us to pattern match at the point of assignment like so:
>
> Color(byte red, byte green, byte blue) color = someFactory();
>
> This would be a great addition to pattern matching.

Imperative pattern matching is reasonable and well understood, but (a) 
it is not yet the highest-leverage remaining pattern matching feature 
(and so remains lower on the queue) and (b) still has several rough 
edges to work out.  There are actually two versions of imperative 
pattern matching that people might want: one which is "total" (it is a 
compile error to try to deconstruct a target with a pattern that is not 
exhaustive, and one which is "partial" (one that just throws on 
non-match, as if you had "cast" the target to the pattern.)   So this is 
on the back burner for now.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20241205/49f0d1b5/attachment.htm>