sumtypes for D (page 2)

On Monday, 28 November 2022 at 15:48:23 UTC, novice2 wrote: >> 2. just implement it and do a PR > > remember @live, named parameters... > 1,3 and 4 wil be endless debates and no results. Actually creating a preview as well can help as then programmers can try it out an observe how behaves in their own code. That can be valuable input for the DIP.

On 11/28/2022 4:43 AM, rikki cattermole wrote: > After doing work on writing up value type exceptions, I have a number of suggestions on improving a more generalized form of sum types :) Looking forward to it!

On 11/28/2022 7:53 AM, IGotD- wrote: > Actually creating a preview as well can help as then programmers can try it out an observe how behaves in their own code. That can be valuable input for the DIP. Implementing it will be a substantial amount of work (as opposed to the trivial ImportC), so I'm reluctant to do so without a pretty positive response.

On 11/28/2022 4:35 AM, Mike Parker wrote: > This gets my vote. I think we should just drop the rule that you can't author your own DIPs. Its only impact has been that your DIPs have stalled. > > I'm planning to modify the DIP process in the new year. Dropping this rule is a change I was considering, so let's just go ahead and do it. > > And for the record, one change I've already decided on is that I'm eliminating the Final Review round. A DIP can still have multiple rounds of Community Review if it goes through significant revision, but once the CR is done, it will now go straight to Formal Assessment. Sounds like a winner.

On Monday, 28 November 2022 at 09:27:11 UTC, Walter Bright wrote: > I've written most of a DIP for one. Should I: I'd like to point out that we still don't have a reasonable collection library because it is not possible to have a user type that has properties similar to a slice (as in T[]). Solving this would also ensure ensure that we can have sumtype as a library that are just as good as the builtin ones. The reason we cannot now is because we cannot build library types that mimic the builtin ones. I would have liked you as a leader here to get people to focus here instead of adding to the pile of complexity. There is a runaway pattern in this community to chase the next great thing, not because it is is bringing that much value, but because that's a good distraction from the fundamentals problems that exists.

November 29, 2022

Re: sumtypes for D

Posted by max haughton
in reply to deadalnix

Permalink

max haughton

Posted in reply to deadalnix

Permalink

On Tuesday, 29 November 2022 at 00:02:45 UTC, deadalnix wrote:

On Monday, 28 November 2022 at 09:27:11 UTC, Walter Bright wrote:

I've written most of a DIP for one. Should I:

I'd like to point out that we still don't have a reasonable collection library because it is not possible to have a user type that has properties similar to a slice (as in T[]).

Solving this would also ensure ensure that we can have sumtype as a library that are just as good as the builtin ones. The reason we cannot now is because we cannot build library types that mimic the builtin ones.

I would have liked you as a leader here to get people to focus here instead of adding to the pile of complexity.

There is a runaway pattern in this community to chase the next great thing, not because it is is bringing that much value, but because that's a good distraction from the fundamentals problems that exists.

Built-in sumtypes will unify a lot of codebases if done right: Tuples and sumtypes are to writing beautiful programs what the container issues are to writing beautiful libraries IMO.

Currently you can do a good-ish sumtype as a library, but the ergonomics are fairly meh, exhaustiveness is (impossible?) hard, and so on. The type itself isn't really that interesting, although having them available everywhere under the same design (i.e. covariance without introducing structural typing and so on) is valuable, it's really the operations that tend to come with them that bring the joy.

A mental model for library versus language ADTs that I developed translating Haskell code into D: our current std.sumtyle requires roughly (for N uses of a sumtype's features e.g. constructors etc.) you are basically O(N) identifiers more tired than Haskell. It's close to greatness but no closer IMO.

I will also happily bet a beer (conviently unfalsifiable) that sumtypes and other ML derived features are what get people to stay with languages like the Ferrous one after their initial pitch. They're not the next thing, they're now basically omnipresent in languages that are either new enough or bold enough to include them - people looking at languages solely from the angle of improving C++ have been completely blindsided by this IMO. It's a common retort to say "do it as a library" or even "no one really cares about it that much" and so on but they (including tuples) have quietly transformed much of the industry.

I also don't think this is either or, we should work on the container side (both the community and us two plus anyone else interested) too.

For all we know Walter just threw together some stuff on a whim, hence why he hasn't posted what he has yet. I did something recently too, another attempt at trying to fix ModuleInfo exportation on Windows which hasn't gone great. But yeah ML is the feature set of future successful languages. The more analysis you bake into a language the better its going to be long term and ML features allow you to do this very effectively. Memory safety wrt. data structures is much higher on my list of needs than sum types.

Forums