sumtypes for D (page 5)

On 11/28/2022 6:42 PM, deadalnix wrote: > I have done so numerous times. Every single god damn time you answer the same thing. The n.g. archives can be found here: https://www.digitalmars.com/d/archives/digitalmars/D/index.html It's searchable, but I don't know what to search for.

On Tuesday, 29 November 2022 at 02:53:27 UTC, Adam D Ruppe wrote: > On Tuesday, 29 November 2022 at 02:33:21 UTC, deadalnix wrote: >> I'm literally building a sum type > > Curious, what did you find lacking in std.sumtype? > > Same question to Walter. > > (btw I've never used it myself but this seems an obvious question that needs to be answered by anyone doing their own implementation, in or out of the language) Good question. They didn't work in my case mainly for 2 reasons: - The above mentioned problem with qualifiers. `const SumType(A, B)` is somehow completely unrelated to `SumType(const A, const B)` which is not workable in practice. - I needed a set of implicit conversions between the elements when the sum type is used is certain ways, and as far a I can tell, there is no way to extend std.sumtype to achieve this kind of things.

On Tuesday, 29 November 2022 at 06:45:37 UTC, Walter Bright wrote: > Top level qualifiers can be removed with: > > cast()expression No, this will remove all qualifiers on user defined types. Which is one more reason one cannot provide a user defined type that behave like the builtin ones, and this is something you want to be able to do, for collections, ranges, as well as for sum types.

On 29/11/2022 8:28 PM, Walter Bright wrote: > On 11/28/2022 6:46 PM, rikki cattermole wrote: >> Seriously, 2-3 days an actual dmd compiler dev could probably get ModuleInfo exportation on Windows working correctly and we could get shared library support in D starting to actually be decent. >> >> Just that one fix would mean we could close FOUR issues extremely easily! And add a whole new realm of possibilities for D. > > When posting things like this, links to the bugzilla entries are most appreciated. I take it you haven't been reading my posts about shared library support? They cover my journey on this pretty well, the content isn't really suited to ticket comments so you won't find the interesting stuff there as its mostly just symptoms. https://forum.dlang.org/post/tlqrlu$2lok$1@digitalmars.com

November 29, 2022

Re: sumtypes for D

Posted by deadalnix
in reply to max haughton

Permalink

deadalnix

Posted in reply to max haughton

Permalink

On Tuesday, 29 November 2022 at 03:42:26 UTC, max haughton wrote:

I have met a few people who were specifically turned off of D because they wanted real algebraic data types and pattern matching - as in "that's cute, where's the real thing" when shown library sum types.

It seems like the high impact item here is matching more than the library type. Herb Sutter as excellent work on how to do this in C++, most of it is applicable to D.

Well one is template bloat. I happily (well, readily) concede this is relatively minor compared to the type system as a whole but instantiating any operation on a sumtype is not cheap. One of the primary complaints is the build and link time which usually means some kind of explosive template code.

You are missing the forest for the trees, a bit. Yes, template bloat is an issue, but there is a meta issue in this thread: lack of tools. Many issue can be "solved" not by solving anything, but by making them easily visible, discoverable, etc...

Concrete exemple: do you know that the initial version of programs written in C++ are typically slower than their counter parts in Java? Large companies such as Google have a ton of data on this. So why is Google still writing high performance code in C++? because in C++, the have the tool to optimize further, and, as a result, while the initial version will be slower (on the balance of probabilities), the C++ one can be optimized more and more over time in ways that the Java one cannot.

But here is where this become relevant to this specific issue: every time we change the language, we break tools. And we change the language all the time, with no easily predictable schedule, and often for value add that are at best marginal.

To reuse Hazlitt's lingo, this is the unseen here. The cost we are paying but we are not seeing is the complete lack of a tooling ecosystem, because we keep destroying it before it can grow to a size where it provides value.

I will also note that "actual" people both informally and in a few surveys we've done over the years do consistently ask for this. We don't have to be democracy but an appeal to actual developer's work should be aware of that.

Well take it from someone who has experience building product, some of them are used by hundreds of million of people: this NOT how you want to look at it at all. Classic trap.

There are a few reasons:

As the product builder, you are the expert. You have read all the latest research, you know of all the tradeoffs, you have played with numerous alternatives, etc... At least you should. Your users did not. If you base yourself on your users, you will build something inferior, and if your user know better than you do, then you have a big problem, because you are not expert enough, and MUST tackle this. Failure to do so means that you will build, at best, an average product, but likely worse than average because it'll lack a unified vision.
Even ignoring your first point, the sample is horribly biased. Indeed, the people you have in there, are mostly people who are not bothered by the worse features of your product. This is why the people who build great product are typically relentless in their criticism of what they've built. They know that, to get to the next level, they need to fix problem that very few in their user base complain about, and if they don't take on that role, nobody will. The people who see the flaws are, for the most part, not in your sample.

I also note that many many codebases have something that amounts to a sum type one way or another. As a result of that we have many incompatible sumtype implementations. They're also completely opaque to tooling.

Very true. This can mean a few things. Maybe that sum types in the languages are needed, but also maybe that there are more fundamental problems that compel people to roll their own.

There used to be a ton of string types in C++ circa 15 years ago. Literally every project came with its own string type. The solution wasn't to make string a part of the language, but rather to ensure there were the tools available to make the one from the standard lib really good, to such a degree that people felt compelled to get rid of their own versions.

You will note that this is not always the right path, but this is the first path that you want to consider, because the compounding effect are much, much much greater. If you fix the language such as the library solution is world class, then you also fix the same problem for a ton of other unrelated libraries solutions for unrelated problems.

And then, maybe, you reach a point where you actually need to bake things into the language. But for as long as you have not reached the above stage, you simply don't know.

Without knowing the problem in more detail I have nothing. Even if the solution was hacky it's better to have magic contained in something the compiler controls then a foreign library IMO.

Yes, and what I'm telling you is that the problems who'd deserve to be solved here are not specific to sum types, at least, not the worse offenders. Therefore, baking a special case solution for sum type would:
1/ Not solve the core issue to begin with.
2/ Make the core issue harder to solve, because it now has to be compatible with whatever is done for sum types.
3/ Increase language complexity, which means more bugs and other problem in practice.
4/ Tooling problems.

Forums