www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Interesting paper on composing type definitions

reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
https://pdfs.semanticscholar.org/5de7/591a853ec947f8de7dc70df0b2ecc38b8774.pdf 
-- Andrei
Mar 04 2017
next sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
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?
Mar 05 2017
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Mar 05 2017
parent reply Enamex <enamex+d outlook.com> writes:
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'.
Mar 06 2017
next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
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.
Mar 06 2017
parent bpr <brogoff gmail.com> writes:
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.
Mar 06 2017
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Mar 06 2017