Thread overview | |||||||||
---|---|---|---|---|---|---|---|---|---|
|
March 04, 2017 Interesting paper on composing type definitions | ||||
---|---|---|---|---|
| ||||
https://pdfs.semanticscholar.org/5de7/591a853ec947f8de7dc70df0b2ecc38b8774.pdf -- Andrei |
March 05, 2017 Re: Interesting paper on composing type definitions | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu | 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?
|
March 05, 2017 Re: Interesting paper on composing type definitions | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu | 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
|
March 06, 2017 Re: Interesting paper on composing type definitions | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu | 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'.
|
March 06, 2017 Re: Interesting paper on composing type definitions | ||||
---|---|---|---|---|
| ||||
Posted in reply to Enamex | 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.
|
March 06, 2017 Re: Interesting paper on composing type definitions | ||||
---|---|---|---|---|
| ||||
Posted in reply to Timon Gehr | 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. |
March 06, 2017 Re: Interesting paper on composing type definitions | ||||
---|---|---|---|---|
| ||||
Posted in reply to Enamex | 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
|
Copyright © 1999-2021 by the D Language Foundation