unfolder
Repository with code snippets that accompany episodes of The Haskell Unfolder (by well-typed)
core-libraries-committee | unfolder | |
---|---|---|
60 | 3 | |
95 | 64 | |
- | - | |
5.3 | 6.6 | |
20 days ago | 15 days ago | |
Haskell | ||
- | - |
The number of mentions indicates the total number of mentions that we've tracked plus the number of user suggested alternatives.
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
core-libraries-committee
Posts with mentions or reviews of core-libraries-committee.
We have used some of these posts to build our list of alternatives
and similar projects. The last one was on 2023-10-07.
-
An alternative front end for Haskell?
> But the obvious and easy solution in the current language would be to return Maybe, which isn't done because there's a feeling that it's not a big enough step to be worth the effort, and dependent types will eventually solve this anyway.
That's not why it's not done. listToMaybe already exists[1] and you can't change the type of head without breaking everyone's code, so head in the next version of base will come with a warning[2] and that's about as much as you can do whilst still maintaining backwards compatibility.
[1] https://www.stackage.org/haddock/lts-21.14/base-4.17.2.0/Dat...
[2] https://github.com/haskell/core-libraries-committee/issues/8...
- Proposal: extend Data.Bitraversable API with firstA and secondA
-
Core Libraries Committee (CLC) Update: June 2023
The proposal to add quantified superclasses to Bifoldable and Bitraversable has been reopened too. https://github.com/haskell/core-libraries-committee/issues/93
-
Monthly Hask Anything (June 2023)
My understanding is any change to base requires an explicit proposal, and if it involves adding stuff to Data.List that could break other packages, that will be taken into account. But it's not a dealbreaker, e.g. a recent proposal to add Data.List.unsnoc got accepted.
- Proposal: add foldl' to Prelude
- プロポーザル: Data.List.unsnoc :: [a] -> Maybe ([a], a) を追加する
- Proposal: add Data.List.unsnoc :: [a] -> Maybe ([a], a)
- Proposal: add instance {Enum, Bounded, Num, Real, Integral} Compose f g a
-
The Haskell Unfolder Episode 2: quantified constraints
Bifunctor has one as well (issue)
- Proposal: expose sized integer types {Int,Word}{8,16,32,64} from Prelude
unfolder
Posts with mentions or reviews of unfolder.
We have used some of these posts to build our list of alternatives
and similar projects. The last one was on 2023-05-03.
- The Haskell Unfolder Episode 7: learning by testing
-
The Haskell Unfolder Episode 3: injectivity
We also have a GitHub repository with the code samples from the episodes: https://github.com/well-typed/unfolder
- The Haskell Unfolder Episode 2: quantified constraints
What are some alternatives?
When comparing core-libraries-committee and unfolder you can also consider the following projects:
ghc-proposals - Proposed compiler and language changes for GHC and GHC/Haskell
profunctors - Haskell 98 Profunctors
snake-fury - a challenge for Haskell beginners