digitalmars.D - Interesting paper on composing type definitions
- Andrei Alexandrescu (2/2) Mar 04 2017 https://pdfs.semanticscholar.org/5de7/591a853ec947f8de7dc70df0b2ecc38b87...
- Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= (4/5) Mar 05 2017 What did you find interesting about it?
- Andrei Alexandrescu (7/9) Mar 05 2017 An idea inspired by this paper would be a type Sum such that Sum!(A, B)
- Enamex (8/18) Mar 06 2017 I haven't read the paper yet but doesn't that sound exactly
- Timon Gehr (2/19) Mar 06 2017 I don't think you are. The paper is using non-standard terminology.
- bpr (9/26) Mar 06 2017 You're right. 'Sum' in that paper joins the interfaces, so it's
- Andrei Alexandrescu (2/16) Mar 06 2017 Yah, it's an overloaded use of the term. -- Andrei
https://pdfs.semanticscholar.org/5de7/591a853ec947f8de7dc70df0b2ecc38b8774.pdf -- Andrei
Mar 04 2017
On Sunday, 5 March 2017 at 03:36:15 UTC, Andrei Alexandrescu wrote:https://pdfs.semanticscholar.org/5de7/591a853ec947f8de7dc70df0b2ecc38b8774.pdf -- AndreiWhat did you find interesting about it? How is their sum-type different from multiple inheritance?
Mar 05 2017
On 3/4/17 10:36 PM, Andrei Alexandrescu wrote:https://pdfs.semanticscholar.org/5de7/591a853ec947f8de7dc70df0b2ecc38b8774.pdf -- AndreiAn 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
On Monday, 6 March 2017 at 01:37:18 UTC, Andrei Alexandrescu wrote:On 3/4/17 10:36 PM, Andrei Alexandrescu wrote: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'.https://pdfs.semanticscholar.org/5de7/591a853ec947f8de7dc70df0b2ecc38b8774.pdf -- AndreiAn 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 06 2017
On 06.03.2017 21:49, Enamex wrote:On Monday, 6 March 2017 at 01:37:18 UTC, Andrei Alexandrescu wrote:I don't think you are. The paper is using non-standard terminology.On 3/4/17 10:36 PM, Andrei Alexandrescu wrote: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'.https://pdfs.semanticscholar.org/5de7/591a853ec947f8de7dc70df0b2ecc38b8774.pdf -- AndreiAn 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 06 2017
On Monday, 6 March 2017 at 21:22:46 UTC, Timon Gehr wrote:On 06.03.2017 21:49, Enamex wrote: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 Monday, 6 March 2017 at 01:37:18 UTC, Andrei Alexandrescu wrote:I don't think you are. The paper is using non-standard terminology.On 3/4/17 10:36 PM, Andrei Alexandrescu wrote: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'.https://pdfs.semanticscholar.org/5de7/591a853ec947f8de7dc70df0b2ecc38b8774.pdf
Mar 06 2017
On 3/6/17 3:49 PM, Enamex wrote:On Monday, 6 March 2017 at 01:37:18 UTC, Andrei Alexandrescu wrote:Yah, it's an overloaded use of the term. -- AndreiOn 3/4/17 10:36 PM, Andrei Alexandrescu wrote:I haven't read the paper yet but doesn't that sound exactly opposite to what 'sum types' is usually used to mean?https://pdfs.semanticscholar.org/5de7/591a853ec947f8de7dc70df0b2ecc38b8774.pdf -- AndreiAn 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 06 2017