sumtype 0.5.0

Everlast Everlast at For.Ever
Fri Aug 10 21:28:40 UTC 2018


On Friday, 10 August 2018 at 19:19:39 UTC, Paul Backus wrote:
> On Friday, 10 August 2018 at 13:11:13 UTC, Everlast wrote:
>> On Friday, 10 August 2018 at 12:35:18 UTC, Everlast wrote:
>>>
>>> It would be nice if some actual examples could be given. The 
>>> help on dub is a bit confusing because the the code is not 
>>> complete.
>
> In addition to the example on the dub page, there are a some in 
> the API docs at https://pbackus.github.io/sumtype/sumtype.html 
> that go into more detail.
>
> If by "not complete" you mean that they lack a `main` function, 
> that's because they're defined as `unittest` blocks in the 
> source. This ensures that they are always correct and 
> up-to-date with the latest version of sumtype. I hope you will 
> agree that having to type `void main()` and a couple braces is 
> an acceptable price to pay for such quality assurance. :)

No, I was thinking of the dub page. Is saw the unit tests which 
were better.

>
>> Also, I'm curious how one can handle a collection of types 
>> with match?
>>
>> Suppose I have SumType!(int, float, string)
>>
>> and I wanted a generic match on int and float. Something like
>>
>> (int | float _) => would be awesome, but that is invalid.
>>
>> [...]
>
> You can do this with a template handler that introspects on the 
> type of its argument:
>
> (num) {
>     alias T = typeof(num);
>     static assert(is(T == int) || is(T == float));
>     // code to handle int or float goes here
> }
>
> If you want nicer syntax, you can factor out the type 
> assertions into a template wrapper:
>
> SumType!(int, float, string) x;
> x.match!(
>     acceptOnly!(int, float,
>     	num => writeln("number")
>     ),
>     (string _) => writeln("string")
> );
>
> Full code here: https://run.dlang.io/is/MrzF5n
>

Ok, thanks!

>> Also, a full algebra would be nice ;)
>>
>> alias X = SumType!(int, float, string)
>> alias Y = SumType!(complex, vector)
>>
>> alias Z = SumType.Union(X,Y);
>>
>> Z is a "super type" as could have been expressed as
>>
>> alias Z = SumType!(int, float, string, complex, vector).
>
> You can do this already with `alias Z = 
> SumType!(NoDuplicates!(X.Types, Y.Types));`, using 
> `std.meta.NoDuplicates`. I don't know of an equivalent template 
> for getting the intersection of two type sequences, but you 
> could probably cobble something together with `std.meta.Filter`.
>

Yes, but

>> alias Z = SumType.Union(X,Y);

is not the same as

>> alias Z = SumType!(int, float, string, complex, vector).

In the first case Z is actually a union of 2 types while in the 
second it is of 5. There is a subtle difference in that in the 
second case the types lose relation. E.g., there is no way to 
recover X or Y from Z but in the first we can:

We can see this explicitly:

union X
{
    int;
    float;
    string;
}


union Y
{
    complex;
    vector;
}

union Z
{
    X;
    Y;
}

union ZZ
{
    int;
    float;
    string;
    complex;
    vector;
}


ZZ is flat while Z is hierarchical.

I'm not sure how SumType deals with type info, if it is local or 
global. If it were global, then Z would definitely be different 
than ZZ.

>> except, of course, Z would be typed in terms of X and Y.
>>
>> [...]
>
> What you are describing here is, essentially, an entirely new 
> type system. It's interesting as a thought experiment, but 
> ultimately, D already has a type system, and I would much 
> rather have SumType work with the existing system than invent 
> its own.

It's not entirely different but a different representation. 
Ultimately it should be isomorphic.

> (Also, what you call `ProdType` already exists. It's called 
> `Tuple`, and is located in the module `std.typecons`.)


Yes, Tuple is a product over types, but we are talking about in 
the context of including type info for matching and such which 
tuples don't directly have.

What I'm ultimately talking about is to allow one to compare 
these types, to match, etc in a way that is more sophisticated 
than having to match directly on the types.

E.g., what if we wanted to match on "inheritance"? How can that 
be done?

Using the Z above, We could write a match on X and or Y. This is 
more direct than using ZZ, although we could do somewhat just as 
easy. But suppose we would like to match for anything that uses X?

Z, which uses X, acts very similar to a derived class and this 
info can be used to provide more appropriate matching.


D already has a great type system with it's many advanced 
features but these are pretty much static while the point of sum 
types is to provide dynamic resolution. Maybe some combination 
could be used. Since SumType is already a D type it can use the 
D's typing features but since SumType is effectively sealed in 
this sense it doesn't work too well.

e.g.,

alias Z = SumType!(X,Y) is a type itself and effectively inherits 
from X and Y but this relationship is not expressed in any 
meaningful way in SumType.

Maybe SumType!(X,Y) could return a new type that is a class that 
inherits from X and Y? (unfortunately this can't work because of 
single inheritance but these types could probably be wrapped in 
interfaces and properties could be used)

Then, say

alias Z = SumType!(X,Y)

is a new type which has all the characteristics of a SumType but 
also can work in the ecosystem of D's type system too.

For example, it would be nice to have relations such as

SumType!(X,Y) : SumType!(X)

or

cast(X)SumType!(X,Y) == X

etc.

This might be require quite a bit more work and I'm not sure if 
it all would work out well or not but if it did it would leverage 
quite a bit of power.










More information about the Digitalmars-d-announce mailing list