Pre-HFTP: GHC should offer low-level logging infrastructure

I think it’s good to have this discussion as openly as possible, yet we as the general public may not be the best people to decide anything. If I vote for this proposal, that won’t convince the authors of Katip to switch the the proposed logging engine.

I’m very in favor of avoiding premature optimization here, especially since doing it in Haskell is the safest route. It’s easy to replace pure Haskell code in a package with calls to GHC primitives later, isn’t it?

So maybe the next phase should be to poll the authors of the biggest Haskell logging libraries about what they would need as common logging primitives and if they’d be willing to switch to them?

In parallel to that, maybe we could write a POC of that API and provide packages for a few algebraic effect libraries? I’d be happy to write polysemy-common-logging

This is now fixed by @Lysxia in Make putStrLn more atomic with line or block buffering by Lysxia · Pull Request #600 · haskell/text · GitHub.

5 Likes