www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - sumtype 0.5.0

reply Paul Backus <snarwin gmail.com> writes:
SumType is a generic sum type for modern D. It is meant as an 
alternative to `std.variant.Algebraic`.

Features:
   - Pattern matching, including support for structural matching 
(*)
   - Self-referential types, using `This`
   - Works with `pure`, ` safe`, ` nogc`, and `immutable` (*)
   - Zero runtime overhead compared to hand-written C
     - No heap allocation
     - Does not rely on runtime type information (`TypeInfo`) (*)

Starred features (*) are those that are missing from `Algebraic`.

Code examples are available in the documentation (linked below).

New since the last announced version, 0.3.0:
   - Types with destructors and postblits are now handled 
correctly.
   - Unreachable handlers in `match` calls are now a compile-time 
error.
   - `match` handlers can now operate on the stored value by 
reference.
   - A new method, `tryMatch`, allows for non-exhaustive pattern 
matching.
   - Various small improvements to the documentation.

Documentation: https://pbackus.github.io/sumtype/sumtype.html
DUB: https://code.dlang.org/packages/sumtype
Github: https://github.com/pbackus/sumtype
Aug 08
next sibling parent reply vit <vit vit.vit> writes:
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`.

 Features:
   - Pattern matching, including support for structural matching 
 (*)
   - Self-referential types, using `This`
   - Works with `pure`, ` safe`, ` nogc`, and `immutable` (*)
   - Zero runtime overhead compared to hand-written C
     - No heap allocation
     - Does not rely on runtime type information (`TypeInfo`) (*)

 Starred features (*) are those that are missing from 
 `Algebraic`.

 Code examples are available in the documentation (linked below).

 New since the last announced version, 0.3.0:
   - Types with destructors and postblits are now handled 
 correctly.
   - Unreachable handlers in `match` calls are now a 
 compile-time error.
   - `match` handlers can now operate on the stored value by 
 reference.
   - A new method, `tryMatch`, allows for non-exhaustive pattern 
 matching.
   - Various small improvements to the documentation.

 Documentation: https://pbackus.github.io/sumtype/sumtype.html
 DUB: https://code.dlang.org/packages/sumtype
 Github: https://github.com/pbackus/sumtype
Nice, but destructor SumType.~this() can call destroy on reference type like class: bool destructed = false; class C{ ~this(){ destructed = true; } } struct S{ ~this(){ } } void main(){ auto c = new C; { auto st = SumType!(C, S)(c); } assert(destructed == true); }
Aug 08
parent Paul Backus <snarwin gmail.com> writes:
On Wednesday, 8 August 2018 at 21:57:07 UTC, vit wrote:
 Nice,
 but destructor SumType.~this() can call destroy on reference 
 type like class:
Whoops. Good catch. I've pushed a fix, tagged as version 0.5.1.
Aug 08
prev sibling next sibling parent reply Seb <seb wilzba.ch> writes:
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`.

 Features:
   - Pattern matching, including support for structural matching 
 (*)
   - Self-referential types, using `This`
   - Works with `pure`, ` safe`, ` nogc`, and `immutable` (*)
   - Zero runtime overhead compared to hand-written C
     - No heap allocation
     - Does not rely on runtime type information (`TypeInfo`) (*)

 Starred features (*) are those that are missing from 
 `Algebraic`.

 Code examples are available in the documentation (linked below).

 New since the last announced version, 0.3.0:
   - Types with destructors and postblits are now handled 
 correctly.
   - Unreachable handlers in `match` calls are now a 
 compile-time error.
   - `match` handlers can now operate on the stored value by 
 reference.
   - A new method, `tryMatch`, allows for non-exhaustive pattern 
 matching.
   - Various small improvements to the documentation.

 Documentation: https://pbackus.github.io/sumtype/sumtype.html
 DUB: https://code.dlang.org/packages/sumtype
 Github: https://github.com/pbackus/sumtype
That's a pretty cool library! I added it to run.dlang.io, s.t. it's easy for people to play with it and share examples, e.g. https://run.dlang.io/is/5znJXH (It uses the version from DUB and updates itself once daily, but somehow dub still lists 0.4.1 at the moment)
Aug 08
parent reply Seb <seb wilzba.ch> writes:
On Thursday, 9 August 2018 at 00:07:05 UTC, Seb wrote:
 (It uses the version from DUB and updates itself once daily, 
 but somehow dub still lists 0.4.1 at the moment)
It looks like you didn't push the git tag to GitHub: https://github.com/pbackus/sumtype/releases
Aug 08
parent reply Paul Backus <snarwin gmail.com> writes:
On Thursday, 9 August 2018 at 00:11:22 UTC, Seb wrote:
 On Thursday, 9 August 2018 at 00:07:05 UTC, Seb wrote:
 (It uses the version from DUB and updates itself once daily, 
 but somehow dub still lists 0.4.1 at the moment)
It looks like you didn't push the git tag to GitHub: https://github.com/pbackus/sumtype/releases
One of these days, I'll learn. Should be there now.
Aug 08
next sibling parent reply vit <vit vit.vit> writes:
On Thursday, 9 August 2018 at 01:04:43 UTC, Paul Backus wrote:
 On Thursday, 9 August 2018 at 00:11:22 UTC, Seb wrote:
 On Thursday, 9 August 2018 at 00:07:05 UTC, Seb wrote:
 (It uses the version from DUB and updates itself once daily, 
 but somehow dub still lists 0.4.1 at the moment)
It looks like you didn't push the git tag to GitHub: https://github.com/pbackus/sumtype/releases
One of these days, I'll learn. Should be there now.
SumType without initialization doesn't fail if first type has disabled this(). In SumType need be something like this: struct SumType(...){ ///... static if(Types.length > 0 && __traits(compiles, (){Types[0] tmp;}()) == false){ ///Types[0] has disabled this() disable this(); } ///.... } method toString is not template. (why is there in the first place?) SumType can have zero TypeArgs but then tryMatch fail: auto st = SumType!(); st.tryMatch!((_) => 1); //fail at compile time with bad error message. in matchImpl can by something like this: static if(Types.length == 0){ static if(exhaustive) { static assert(0, "No value to match"); } else { throw new MatchException("No value to match"); } } else{ ///... } or: struct SumType(TypeArgs...) if(TypeArgs.length > 0){ }
Aug 09
parent Paul Backus <snarwin gmail.com> writes:
On Thursday, 9 August 2018 at 07:52:12 UTC, vit wrote:
 SumType without initialization doesn't fail if first type has 
  disabled this().
It did fail for me, but it also failed *with* initialization too, so there was definitely a bug there.
 method toString is not template. (why is there in the first 
 place?)
Mainly it's there so I can do `writeln(sumTypeInst);` without writing out the full `match` call every time. I can't see any reason why it should be a template.
 SumType can have zero TypeArgs but then tryMatch fail:

 [...]

 struct SumType(TypeArgs...)
 if(TypeArgs.length > 0){
 }
The second option is what `Algebraic` does, and it seems like the most sensible solution to me.
Aug 09
prev sibling next sibling parent vit <vit vit.vit> writes:
On Thursday, 9 August 2018 at 01:04:43 UTC, Paul Backus wrote:
 ...
safe opAssign can call system postblit: bool moved = false; struct S{ this(this) system{ moved = true; } } void main() safe{ auto st = SumType!(S).init; st = S.init; assert(moved == true); } change: () trusted { moveEmplace(rhs, storage.values[i]); }(); to: moveEmplace(rhs, *(() trusted => &storage.values[i])());
Aug 09
prev sibling parent vit <vit vit.vit> writes:
On Thursday, 9 August 2018 at 01:04:43 UTC, Paul Backus wrote:
 On Thursday, 9 August 2018 at 00:11:22 UTC, Seb wrote:
 On Thursday, 9 August 2018 at 00:07:05 UTC, Seb wrote:
 (It uses the version from DUB and updates itself once daily, 
 but somehow dub still lists 0.4.1 at the moment)
It looks like you didn't push the git tag to GitHub: https://github.com/pbackus/sumtype/releases
One of these days, I'll learn. Should be there now.
ignore the message with opAssign, my version doesnt work :)
Aug 09
prev sibling next sibling parent reply Paul Backus <snarwin gmail.com> writes:
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
Aug 09
parent reply Everlast <Everlast For.Ever> writes:
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.
Aug 10
parent reply Everlast <Everlast For.Ever> writes:
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 ;)
Aug 10
parent reply Paul Backus <snarwin gmail.com> writes:
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. :)
 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
 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`.
 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. (Also, what you call `ProdType` already exists. It's called `Tuple`, and is located in the module `std.typecons`.)
Aug 10
parent reply Everlast <Everlast For.Ever> writes:
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.
Aug 10
parent Paul Backus <snarwin gmail.com> writes:
On Friday, 10 August 2018 at 21:28:40 UTC, Everlast wrote:
 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: [...] ZZ is flat while Z is hierarchical.
If you want to nest SumTypes, there's nothing stopping you from doing that already. `alias Z = SumType!(X, Y);` will work just fine. I wouldn't necessarily recommend it, since each layer introduces additional memory overhead to store the type tag, but it will work.
 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.
I assume by type info, you mean the tag values? If so, they're local to each instantiation of SumType. For example, in SumType!(A, B), a tag value of `0` corresponds to the type `A`, whereas in SumType!(C, D), the same tag value of `0` corresponds to the type `C`.
 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.
I think we may each have a slightly different idea of what "inheritance" means, in this context. When you say "Z inherits from X and Y", I interpret that as meaning "Z is a subtype of X and Y"--which isn't true. A subtype should obey the substitutability principle: anywhere I can use an object of the supertype, I should be able to substitute an object of the subtype, and my program should still be correct when I do. But suppose I have a function that accepts an X, and I pass it a Z instead. What happens if it turns out, at runtime, that the Z contains a Y? The function won't be prepared to handle it--in other words, my program is now incorrect. That means the substitution was invalid, and Z is not a subtype of X after all. Now, the relationship *does* hold in the opposite direction: if I have a function that accepts a Z, I can pass it an X, and it will be able to handle it. Granted, I'll have to do a little bit of extra typing to wrap the X (i.e., `f(Z(x))` rather than just `f(x)`), because D doesn't allow user-defined implicit conversions, but that's not a terribly large burden. (And if I really want to write `f(x)`, I can always define an overload of `f` that takes an `X` argument and forwards to the `Z` version.)
 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)
It sounds like I may not have been clear enough about what SumType's goal actually is. SumType's goal is not, and has never been, to be a feature-complete alternative to OOP language features like classes, interfaces, and inheritance. Those features already exist in D; there's no need to duplicate them. SumType's goal is, instead, to provide a much more limited, much less flexible version of polymorphism--one that requires every possible "subclass" (i.e., member type) and every "method override" (i.e., match handler) to be fixed up-front, in one place, at compile time. You cannot add new member types to an existing SumType, the way you can add new derived classes to an existing base class--and this is by design! Why is SumType designed this way? Because it turns out that this very limited version of polymorphism can be implemented *much* more efficiently than the real thing. It doesn't require virtual methods, it doesn't require heap allocation, and it doesn't require runtime type information. In fact, the only thing keeping SumType from being BetterC compatible right now is the fact that it uses DRuntime features *during CTFE*! Anyway, I hope I've explained things clearly enough now to avoid further misunderstanding. Please let me know if you have any more questions or ideas--I really appreciate the thought you've put into this discussion.
Aug 10
prev sibling parent Paul Backus <snarwin gmail.com> writes:
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`.
New point release, 0.5.3, with the following updates: - SumType now uses the smallest possible integer type for its tag (e.g., `ubyte` if the number of types is less than 255). - A bug involving structs with invalid .init values has been fixed.
Aug 22