Interesting paper on composing type definitions

[Timon Gehr via Digitalmars-d]

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.