Hackage :: [Package]

mtl-uplift: Lift substacks of monad transformer stacks

[ control, library, mit ] [ Propose Tags ]

Lift substacks of monad transformer stacks.

[Skip to Readme]

Modules

[Index] [Quick Jump]

Downloads

Maintainer's Corner

Package maintainers

For package maintainers and hackage trustees

Candidates

  • No Candidates
Versions [RSS] 0.1.0.0, 0.1.0.1
Dependencies base (>=4.12 && <4.15), mtl (>=2.2) [details]
License MIT
Copyright 2020 Samuel Schlesinger
Author Samuel Schlesinger
Maintainer sgschlesinger@gmail.com
Category Control
Home page https://github.com/SamuelSchlesinger/mtl-uplift
Bug tracker https://github.com/SamuelSchlesinger/mtl-uplift/issues
Source repo head: git clone https://github.com/samuelschlesinger/mtl-uplift
Uploaded by sgschlesinger at 2020-09-27T20:09:13Z
Distributions
Downloads 304 total (12 in the last 30 days)
Rating (no votes yet) [estimated by Bayesian average]
Your Rating
  • λ
  • λ
  • λ
Status Docs available [build log]
Last success reported on 2020-09-27 [all 1 reports]

Readme for mtl-uplift-0.1.0.0

[back to package description]

mtl-uplift

Uplift entire substacks of monad transformer stacks, boilerplate free!

Many industry Haskell programmers are all too familiar with code like:

lift . lift . lift . lift . lift . lift . lift . lift . lift . lift . lift . lift . lift $ do
  blah

This may or may not be an exaggeration. Now, we can just write the much less visually annoying:

uplift @TopOfSubstackT $ do
  blah

This relieves the programmer from having to do any bookkeeping about what level of their greater stack their substack lives at, but just to know which monad tops it. Beyond that, if we transform our stack, with the old code we would potentially have to modify the number of calls to lift, but now, as long as we still want to uplift a substack with the same top, we don't have to. Isn't that uplifting?