Proposal: Switch to RIO prelude
I've been using RIO for several weeks now and while still in early stages it's been proving to be more solid than the standard library. RIO is a drop-in replacement prelude specifically aimed at building user-facing apps and has a very coherent design philosophy. Some of the benefits that are relevant here include:
- Less dependency overhead (bytestring, containers, directory, filepath, text, time can all be made redundant) , and less import statements overall.
- Clear separation of total and partial functions by namespace
- tracing and very pretty logging functions out of the box, that can tee out simultaneously to multiple filehandlers.
Displaytypeclass and related functions which act as a human-readable
Show, to prevent overloading
Showfor that purpose (which breaks the contract with
- The essential parts of
Control.Arrowreexported by default.
- A more general replacement for
unliftio, (from my naive understanding of what
Bustle/Application/Monad.hsis doing with glib).
- An emphasis on using
Texteverywhere to avoid Haskell string horror (and
Textis faster than
I've made a mockup of what it might look like to just swap out prelude for rio here without taking particular advantage of any features. Some issues are:
- I had to disable gettext in the stack configuration to get it to build, how it's arranged currently doesn't seem to play well with NoImplicitPrelude for some reason. Maybe this can be reworked/upstreamed first?
- Still have to import fromEnum in normal Prelude which I've opened an issue in RIO for here
- Need to hide the
onfunctions in RIO because they collide with GTK functions.