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