plan-applicative: Applicative/Arrow for resource estimation and progress tracking.

[ bsd3, control, library ] [ Propose Tags ]

This module contains a writer-like Applicative for giving monoidal annotations to underlying computations. The annotations are available before running the computations. It also allows tagging different parts of a computation as separate steps, so that progress notifications can be emitted during execution. Optional steps are allowed.

[Skip to Readme]


Maintainer's Corner

Package maintainers

For package maintainers and hackage trustees


  • No Candidates
Versions [RSS],,,
Change log
Dependencies base (>=4.6 && <5), bifunctors (>=5.4 && <5.6), comonad (>=5 && <6), containers (>=0.5.5 && <0.7), profunctors (>=5.2 && <5.4), streaming (>=0.1.4 && <0.3), transformers (>=0.4.2 && <0.6) [details]
License BSD-3-Clause
Author Daniel Diaz
Category Control
Source repo head: git clone
Uploaded by DanielDiazCarrete at 2018-08-18T11:44:49Z
Reverse Dependencies 1 direct, 0 indirect [details]
Downloads 2460 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 2018-08-18 [all 1 reports]

Readme for plan-applicative-

[back to package description]


A writer-like Applicative/Arrow for resource estimation and progress tracking.


I run scripts in my machine. Their logic is simple and predictable, even if the steps are many and take long to complete.

The following infuriating situations happen:

  • The script fails at minute 45 because of a syntax error.
  • The script fails at minute 45 because it requests a missing resource whose availability could have been checked when the script started.
  • It is difficult to ascertain how far along the execution we are at minute 45.

The first problem is solved by using a statically typed language or, for dynamic languages, some kind of static analysis tool.

For the second problem, we need to have a summary of the resources that the computation will require, before running the computation itself. This can be done by hand, adding a new check at the beginning of the script when we change something further down. But it's easy to forget to do so, and the initial checks can become out of sync with the main code. It would be nice if each step of the computation foresaw its own resource needs and these accumulated automatically as we composed the steps.

For the third problem, we need a channel that notifies you whenever a step of the computation starts or finishes. Bonus points if nested steps are supported.


Currently the ApplicativeDo extension doesn't work very well with this package's Applicative because an extant bug in GHC: #10892. Sequencing actions whose values are ignored gives an error.


  • StaticArrow from the arrows package.

  • Not exactly an inspiration (as I don't understand the stuff well enough) but Tomas Petricek's work on "coeffects" seems relevant for helping applications to "fail early". See section 1.1 of his thesis.