v0.10 wish list

[jonascarpay]

Here's a list of breaking changes to consider for v0.10.

• Change SystemT to an ReaderT alias. This is in light of Add MonadUnliftIO instance for SystemT #123, and the list of derived instances getting a little ridiculous.
  • Would we use MonadReader everywhere?
  • Instead of generating Has instances, would we generate MonadReader (Store c) instances?
• Restructure or rename Experimental.
• Use and enforce ormolu and cabal-fmt for formatting (not technically API breaking)

[jship]

In light of apecs already providing a Monad m => MonadReader w (SystemT w m) instance (as opposed to MonadReader r m => MonadReader r (SystemT w m)) and not providing an mtl-style MonadSystem class, it makes sense and simplifies things for SystemT to be an alias of ReaderT. Deps-wise, exceptions and unliftio-core could be removed right away with the alias approach.

The one slight advantage towards the latter instance being provided along with a MonadSystem class is that users could use mtl-style over transformer stacks that include both SystemT and ReaderT. The big disadvantage though is that it's more maintenance due to mtl's n^2 instances, and so doesn't seem worth it considering I don't see any existing or closed issues where requests have been made to support mtl-style in the first place.

• Would we use MonadReader everywhere?
• Instead of generating Has instances, would we generate MonadReader (Store c) instances?

I think with SystemT becoming an alias for ReaderT, we can take advantage of that specialization and replace the dependency on mtl with transformers. Has instances could still be generated, but the getStore body could call transformers asks instead of mtl's asks. Any downstream code already calling mtl ask/asks would work with transformers ask/asks, and would largely come for free by switching the main Apecs module's import of Control.Monad.Reader to Control.Monad.Trans.Reader.