Sealed types

[forax at univ-mlv.fr]

> De: "Brian Goetz" <brian.goetz at oracle.com>
> À: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "amber-spec-experts" <amber-spec-experts at openjdk.java.net>
> Envoyé: Dimanche 9 Décembre 2018 19:04:40
> Objet: Re: Sealed types

>> We can introduce them as sealed interface (note: interface not type)

> This is a new claim. Why is it that abstract classes can’t be sealed as well?
> (There is less _need_ for this, as abstract classes can use access control on
> their constructors to simulate sealing, but that’s a weak approximation, and
> doesn’t move us towards sums at all.

Abstract class as sum type can be problematic if the subclass has itself a super class (see below). 

>> So either we go with an interface and in that can i think we should support all
>> ways to implement an interface or we go with a sum class and in that case i
>> agree that we do not need to support anonymous classes.

> I think what you’re really saying is: the syntax we pick will put ideas in
> people’s heads, and we should be wary if the most likely ideas it plants are
> not the ones we have in mind. Yes, that’s true. But it doesn’t remotely rise to
> the level of “forced move” that you seem to be implying.

We disagree about the "forced move". But that's the last line of my email, i think the issue i'm taking about before that last sentence is more important. 
So it's not about the syntax, it's about the user model and the runtime model. 

The way to define a sum type is: 
- to list all its component 
- have the subtypes to say that they are part of the sum type. 

If there is no way to implement a sum type i.e. to write 'implements' X in the subclass, we do not have to ask ourselves if we have to support anonymous classes 

The runtime model; 
- is it an interface ? 
- Is it a new kind of type ? 

To illustrate the difference between an interface or a new kind of type, 
if we have: 
sum X { A | X2 } 
sum X2 { B | C } 
if X is an interface, switch(X) requires case A and case X2, if it's a new kind of type, switch(X) requires case A, case B and case C. 

> So rather than pounding the table and saying “it has to be this way”, can we try
> to frame the issue more as a mismatch between the candidate syntax and what we
> expect the user model to be, and work it from that direction?
again, last sentence, i should have removed it, and yes, see above. 

> I don’t think I have to say it out loud, but just to be sure: the syntax should
> not drive the model, it should go the other way. If the syntax we’ve chosen is
> a poor fit for the model, first let’s talk about changing the syntax.

I write a syntax down the same way you have given one, as an example. 

Rémi 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20181209/d92b222d/attachment.html>