sumtype 0.5.0

[Everlast]

On Friday, 10 August 2018 at 12:35:18 UTC, Everlast wrote:
> On Thursday, 9 August 2018 at 15:56:12 UTC, Paul Backus wrote:
>> On Wednesday, 8 August 2018 at 20:54:13 UTC, Paul Backus wrote:
>>> SumType is a generic sum type for modern D. It is meant as an 
>>> alternative to `std.variant.Algebraic`.
>>
>> Version 0.5.2, with fixes for the bugs reported in this 
>> thread, is now available. Thanks to vit for their detailed 
>> feedback!
>>
>> In order to avoid spamming the newsgroup, I'd like to 
>> encourage everyone to submit further bug reports, feature 
>> requests, etc. as Github issues at 
>> https://github.com/pbackus/sumtype/issues
>
> 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.

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.

Of course, there are work arounds but the goal is for 
simplification in a canonical way.

One way would be to be able to call other handlers directly:

(int _) => { return match.float(_); }
(float _) => { ... }

which, say, calls the float delegate. This is just "chaining" but 
is a nice universe syntax and is good if it can be implement(with 
inlining occurring).

Another way would be to allow for "sub-SumType'ing":

alias X = SumType!(int, float, string);

(X.SubType!(int, float) _) { ... }

or whatever, again, a few ways one can go about this.

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).

except, of course, Z would be typed in terms of X and Y.

The difference is that Z is compatible with X and Y. But this 
might require a little work because something like Z.X is not the 
same as X due to the fact that X's typeinfo(an index value?) 
cannot represent Z(it would be nice if it could but I think it 
might be fragile to do so unless hashing solves the problem).

Then intersection can also be defined:

SumType.Intersect(X,Y) = SumType!(Null) = null;

But if Y had a string then

SumType.Intersect(X,Y) = SumType!(string); (which should reduce 
to string)

But the problem is that, a string in X and a string in Y may have 
no relationship programmatically(one may encode a series of bits 
for, say, compression and the other an error string). This then 
requires some way to know which type is being acted on(X or Y) as 
so the in sub-types can be properly interpreted.


If one notices, this is similar to inheritance in that union is 
related to derivation and intersection to reduction. The notions, 
if they can be consistently defined, allows one to build type 
structures that are hierarchically based and parallel classes. In 
fact, classes could be seen as a product of SumTypes on single 
elements:

alias C = ProdType!(SumType!string, SumType!int);

C then would act like a class with a string and int field with 
the functionality of both combined and

class Q;
alias D = ProdType!(SumType!float, C, Q);

would be a derivation from C and Q and adding a float member.

Of course, this would be a lot of work and require mathematical 
consistency and not offer much over the current method(in which 
ultimately it would be equivalent to I believe) but it does 
provide completeness. Of course, I suppose if we were to go down 
that path we'ed then require a full on algebraic system so we 
could do stuff like exponentiation, etc ;)