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

[Brian Goetz]

There was some investigation into exposing invokedynamic (see the video 
"Below the Fold" from JVMLS a few years ago.)  I doubt that this 
entirely solves the issue but it is something we'd like to do someday.


On 12/5/2024 11:32 AM, Glavo wrote:
> Is it possible to solve this issue by making Java support 
> invokeDynamic syntactically?
> Users can provide their own helper classes similar to 
> java.lang.runtime.ObjectMethods to synthesize methods.
>
> Glavo
>
> On Thu, Dec 5, 2024 at 11:16 PM Brian Goetz <brian.goetz at oracle.com> 
> wrote:
>
>
>
>
>     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/0a83b7a4/attachment-0001.htm>