Variants/case classes/algebraic data types/sums/oh my!

[org.openjdk at io7m.com]

'Ello.

On 2016-06-11T12:24:06 -0400
Brian Goetz <brian.goetz at oracle.com> wrote:

> To amplify John's comments -- we are very interested in these topics, 
> but we believe there are some fundamentals that have to be addressed 
> first.  No need to dive into great detail about how great case classes / 
> destructuring pattern matches are; we are more than aware :)

*AHEM*

Yes, they're a serious addiction.

> > I believe that all of the existing languages could benefit from both
> > JVM and Java language support for the types, and I believe that support
> > could be provided with minimal, non-intrusive changes to the virtual
> > machine (an extra piece of class metadata, no new bytecode
> > instructions, a couple of extra syntax rules in the Java language that
> > likely build upon the existing switch statement, and no new keywords).  
> 
> By way of setting expectations .... there are no minimal, non-intrusive 
> language or JVM features.  Usually, it requires a tremendous amount of 
> work to make a feature merely *seem* less intrusive; consider lambdas, 
> which are "just" function literals -- except making them work required 
> entirely overhauling type inference and method overload selection -- 
> which if done right, no one notices.

I guess I was just speaking in relative terms. I'd deem intrusive
changes to be, for example, new bytecode instructions. The addition of
switching on strings, I'd deem as relatively minor (although of course,
I may be totally wrong - perhaps it was a nightmare).

> That said, we're willing to invest in big features -- but as John 
> mentioned, there are some things ahead of this one on the queue, which 
> are probably prerequisites for doing this well.  (For example, value 
> types are a prerequisite for useful tuples.)
> 
> So, with those expectation-settings comments aside, we're interested to 
> see what you come up with, and we encourage you to follow the valhalla 
> discussions to see where we're going.  (In particular, I'm interested in 
> hearing what you think the VM is missing for these features.)

Yep, will do.

I think the bulk of it was being able to specify in class metadata that
a class/interface is sealed (perhaps just ACC_SEALED) and that it has a
given list of immediate child classes (we don't need to talk about the
entire set of descendants of a class, as implementing matching seems
to only require going one inheritance step deep at a time). This
seems to be covered in a more general form in the nestmates proposal, so
maybe I won't actually need to implement much!

M