https://pdfs.semanticscholar.org/5de7/591a853ec947f8de7dc70df0b2ecc38b8774.pdf -- Andrei

On Sunday, 5 March 2017 at 03:36:15 UTC, Andrei Alexandrescu wrote:
> https://pdfs.semanticscholar.org/5de7/591a853ec947f8de7dc70df0b2ecc38b8774.pdf -- Andrei

What did you find interesting about it?

How is their sum-type different from multiple inheritance?

On 3/4/17 10:36 PM, Andrei Alexandrescu wrote:
> https://pdfs.semanticscholar.org/5de7/591a853ec947f8de7dc70df0b2ecc38b8774.pdf
> -- Andrei

An idea inspired by this paper would be a type Sum such that Sum!(A, B) stores both states of A and B and the joint API offered by the two. Would be a good exercise in applying introspection. Also, when there are clashing primitives, Sum might offer the option to make one of the types "dominant", eliminate the function from the joint interface, or disallow composition altogether. -- Andrei

On Monday, 6 March 2017 at 01:37:18 UTC, Andrei Alexandrescu wrote:
> On 3/4/17 10:36 PM, Andrei Alexandrescu wrote:
>> https://pdfs.semanticscholar.org/5de7/591a853ec947f8de7dc70df0b2ecc38b8774.pdf
>> -- Andrei
>
> An idea inspired by this paper would be a type Sum such that Sum!(A, B) stores both states of A and B and the joint API offered by the two. Would be a good exercise in applying introspection. Also, when there are clashing primitives, Sum might offer the option to make one of the types "dominant", eliminate the function from the joint interface, or disallow composition altogether. -- Andrei

I haven't read the paper yet but doesn't that sound exactly opposite to what 'sum types' is usually used to mean?

The value of the variable has to be either A or B. If it stores the status of both then it's basically a struct, right?

Probably I'm misunderstanding your point on composition and 'joint API'.

On 06.03.2017 21:49, Enamex wrote:
> On Monday, 6 March 2017 at 01:37:18 UTC, Andrei Alexandrescu wrote:
>> On 3/4/17 10:36 PM, Andrei Alexandrescu wrote:
>>> https://pdfs.semanticscholar.org/5de7/591a853ec947f8de7dc70df0b2ecc38b8774.pdf
>>>
>>> -- Andrei
>>
>> An idea inspired by this paper would be a type Sum such that Sum!(A,
>> B) stores both states of A and B and the joint API offered by the two.
>> Would be a good exercise in applying introspection. Also, when there
>> are clashing primitives, Sum might offer the option to make one of the
>> types "dominant", eliminate the function from the joint interface, or
>> disallow composition altogether. -- Andrei
>
> I haven't read the paper yet but doesn't that sound exactly opposite to
> what 'sum types' is usually used to mean?
>
> The value of the variable has to be either A or B. If it stores the
> status of both then it's basically a struct, right?
>
> Probably I'm misunderstanding your point on composition and 'joint API'.

I don't think you are. The paper is using non-standard terminology.

On Monday, 6 March 2017 at 21:22:46 UTC, Timon Gehr wrote:
> On 06.03.2017 21:49, Enamex wrote:
>> On Monday, 6 March 2017 at 01:37:18 UTC, Andrei Alexandrescu wrote:
>>> On 3/4/17 10:36 PM, Andrei Alexandrescu wrote:
>>>> https://pdfs.semanticscholar.org/5de7/591a853ec947f8de7dc70df0b2ecc38b8774.pdf
>> I haven't read the paper yet but doesn't that sound exactly opposite to
>> what 'sum types' is usually used to mean?
>>
>> The value of the variable has to be either A or B. If it stores the
>> status of both then it's basically a struct, right?
>>
>> Probably I'm misunderstanding your point on composition and 'joint API'.
>
> I don't think you are. The paper is using non-standard terminology.

You're right. 'Sum' in that paper joins the interfaces, so it's really 'product' in the fairly standard type theory terminology. I wish they hadn't done that, it makes communication harder than it has to be.

Here's a recent post from our cousins in the Rust belt

http://manishearth.github.io/blog/2017/03/04/what-are-sum-product-and-pi-types/

which may make things clearer to people unfamiliar with that terminology.

On 3/6/17 3:49 PM, Enamex wrote:
> On Monday, 6 March 2017 at 01:37:18 UTC, Andrei Alexandrescu wrote:
>> On 3/4/17 10:36 PM, Andrei Alexandrescu wrote:
>>> https://pdfs.semanticscholar.org/5de7/591a853ec947f8de7dc70df0b2ecc38b8774.pdf
>>>
>>> -- Andrei
>>
>> An idea inspired by this paper would be a type Sum such that Sum!(A,
>> B) stores both states of A and B and the joint API offered by the two.
>> Would be a good exercise in applying introspection. Also, when there
>> are clashing primitives, Sum might offer the option to make one of the
>> types "dominant", eliminate the function from the joint interface, or
>> disallow composition altogether. -- Andrei
>
> I haven't read the paper yet but doesn't that sound exactly opposite to
> what 'sum types' is usually used to mean?

Yah, it's an overloaded use of the term. -- Andrei