On 05/07/2018 05:35 PM, Paul Backus wrote:
> 
> Personally, I consider [pattern matching] an essential feature--arguably *the* essential feature--

After having used Nemerle, I tend to agree.

I haven't gotten around to using this yet, but I did take a look at the source and was blown away by how small and simple it is. Kudos!

Oh, and I love that it's much easier to remember how to spell than "Algebraic" :)

That said, it would be really nice if D made it possible for a tool like this to support more things being defined in-line. For example, in Nemerle, it's possible to define a binary tree like this:

---------------------------------
// Mainly from:
// https://github.com/rsdn/nemerle/wiki/Grok-Variants-and-matching
variant Tree {
  | Node {
      left  : Tree;
      elem  : int;
      right : Tree;
    }
  | EmptyLeaf
}
---------------------------------

But AFAIK, in D, each part would have to be defined separately, making the overall structure less clear:

---------------------------------
struct Node {
    Tree* left;
    int   elem;
    Tree* right;
}
struct EmptyLeaf {}
alias Tree = SumType!(Node, EmptyLeaf);
---------------------------------

Of course, that's not your lib's fault, just an unfortunate limitation of D.

On Tuesday, 8 May 2018 at 06:33:38 UTC, TheGag96 wrote:
> Wow.. without comments and unittests, the implementation is only 116 lines. Awesome job. Even now I still find it incredible what D can do. Is Algebraic in the standard library really that bad? And if so, why aren't implementations like this being accepted?

Thanks!

Algebraic isn't terrible, but it has one significant design flaw, which is that it shares its implementation with Variant. Variant doesn't have a fixed list of allowed types, so it requires a much more complex implementation than just a union and an integer tag. By sharing that implementation, Algebraic inherits all the costs of its complexity without getting any of the benefits.

I've never contributed to Phobos, so someone with more experience may have better insight here, but my guess is that changing Algebraic at this point would break too much code to be worth the trouble. Perhaps when sumtype is more mature, though, a case could be made for including it in a separate module.

On Monday, 7 May 2018 at 21:35:44 UTC, Paul Backus wrote:
> On Monday, 7 May 2018 at 19:28:16 UTC, Sönke Ludwig wrote:
>> Another similar project: http://taggedalgebraic.dub.pm/
>
> There's also tagged_union and minivariant on dub, that I've found. I'm definitely far from the first person to be dissatisfied with `Algebraic`, or to try my hand at writing a replacement.
>
> The main difference between all of those and sumtype is that sumtype has pattern matching. Personally, I consider that an essential feature--arguably *the* essential feature--which is why I went ahead with Yet Another implementation anyway.

I agree - it's the same reason I was going to write one. But now I don't have to. :)

Atila

On Sunday, 6 May 2018 at 19:18:02 UTC, Paul Backus wrote:
> [snip]
>   - Zero runtime overhead compared to hand-written C

Just to clarify, would the run-time performance of the length function in the example be equivalent to if it had been specialized for the Rectangular types (e.g. double length(Rectacular r) { ... })? It looks like the match is using compile-time functionality to choose the right function to call, but I wanted to be sure.

On Wednesday, 9 May 2018 at 13:33:44 UTC, jmh530 wrote:
> On Sunday, 6 May 2018 at 19:18:02 UTC, Paul Backus wrote:
>> [snip]
>>   - Zero runtime overhead compared to hand-written C
>
> Just to clarify, would the run-time performance of the length function in the example be equivalent to if it had been specialized for the Rectangular types (e.g. double length(Rectacular r) { ... })? It looks like the match is using compile-time functionality to choose the right function to call, but I wanted to be sure.

What length actually does, after all the compile-time stuff is expanded, is essentially this:

switch(v.tag)
{
    case 0: return sqrt(v.value!Rectangular.x**2 + v.value!Rectangular.y**2);
    case 1: return v.value!Polar.r;
}

It's the same thing you'd get if you were implementing a tagged union by hand in C.

It's not exactly the same as a function specialized for Rectangular, because the entire point of a sum type or tagged union is to allow runtime dispatch based on the tag. However, the process of choosing which function goes with which tag takes place entirely at compile time.

On Wednesday, 9 May 2018 at 14:56:20 UTC, Paul Backus wrote:
> [snip]
>
> What length actually does, after all the compile-time stuff is expanded, is essentially this:
>
> switch(v.tag)
> {
>     case 0: return sqrt(v.value!Rectangular.x**2 + v.value!Rectangular.y**2);
>     case 1: return v.value!Polar.r;
> }
>
> It's the same thing you'd get if you were implementing a tagged union by hand in C.
>
> It's not exactly the same as a function specialized for Rectangular, because the entire point of a sum type or tagged union is to allow runtime dispatch based on the tag. However, the process of choosing which function goes with which tag takes place entirely at compile time.

Thanks. That makes sense.

On Sunday, 6 May 2018 at 19:18:02 UTC, Paul Backus wrote:
> SumType is a generic sum type for modern D. It is meant as an alternative to `std.variant.Algebraic`.

Someone posted a question about this on our subreddit:
https://www.reddit.com/r/d_language/comments/8iz9hw/sumtype_03_sum_type_with_pattern_matching/