not having to use OverloadedStrings (omg my phone just auto completed this??)
Just wait until you’re typing “you shouldn’t un…” and it autocompletes with unsafePerformIO.
Suggestion: freeze “base” and call the new prelude by a new name. Eventually, just let “base” wither away.
On-topic: I see that chessai has the package name std reserved and seemingly unused on Hackage (see here).
I think rather than basing off of base the name of any alternative Prelude (e.g. base-pure or something) that necessitates new users being aware of the original base, that a clean start with something like std (and import Std) could be had with less baggage and then progressively adopted over time.
My main concern here is a “blessed” alternate prelude won’t go far enough in addressing historical baggage and so even with this blessing it will just become an example of the “There are now 15 competing standards” xkcd comic (with base/Prelude still being what people default to far into the future).
I’d like for a future where if I pull in one of the current application development libraries & prelude alternatives, that I’d really now just be pulling in that particular framework’s opinionated app dev-oriented types and functions (e.g. a custom monad, logging, and re-exports of process context handling, probably unliftio, etc.). As most of the rest would be already provided by the HF’s new blessed prelude. And that “rest” is the type of stuff that tends to overlap among the excellent common prelude alternatives now like (but not limited to) relude, protolude and rio.
Anyway, thanks to everyone on the HF/HFWG for suggesting a change in this area 