Workflow
unliftio
Our great sponsors
| Workflow | unliftio | |
|---|---|---|
| 1 | 5 | |
| 42 | 150 | |
| - | 0.0% | |
| 0.0 | 3.9 | |
| almost 8 years ago | 4 months ago | |
| Haskell | Haskell | |
| BSD 3-clause "New" or "Revised" License | MIT License |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
Workflow
-
Event Sourcing
I was part of that debate, I remember a rather interesting point of discussion: Is the main operation "apply" or "dedup"
Apply seems to be the common notion of event sourcing: There is a function apply that takes a state an event and yields a new state. Then, starting in an init state and iteratively applying the entire event history, boom, latest state restored.
Dedup has a lot of charm though: Run and rerun your code, if that step of your code is executed for the first time (no corresponding event in the event history) execute the step and store its result as an event in the history, however, if that step of your code is executed for the second, third time (there is a corresponding event in the event history) do not execute the step and return its result from the event in the history. The Haskell Workflow Package (https://hackage.haskell.org/package/Workflow) is a good example
Temporal follows the second approach, so "proper" Event Sourcing? You be the judge :)
unliftio
-
UnliftIO, ExceptT and Coercible
FWIW, your suggestion is very similar to a proposed instance for MonadUnliftIO (ExceptT e), except that effectfuls use of the type system means that it doesn't suffer from one of the proposed downsides (dubious interaction with catchAny).
-
How introduce `ResourceT` into my stack
Possibly interesting thread here: https://github.com/fpco/unliftio/issues/68
-
Is `MonadBaseControl` dead?
Any way quoting u/snoyberg : https://github.com/fpco/unliftio/issues/17#issuecomment-363655106
-
Try.do is dangerous
That's not true. It's just writing that instance is a bit tricky: https://github.com/fpco/unliftio/issues/68
-
Try.do for recoverable errors in Haskell
However, ExceptT cannot be an instance of MonadUnliftIO – because it necessarily requires multiple exit points. See this discussion which should give you an idea of how hairy and unpredictable this can be.
What are some alternatives?
cloud-haskell - This is an umbrella development repository for Cloud Haskell
recursion-schemes - Generalized bananas, lenses and barbed wire
effect-monad - Provides 'graded monads' and 'parameterised monads' to Haskell, enabling fine-grained reasoning about effects.
lifted-base - IO operations from the base library lifted to any instance of MonadBase or MonadBaseControl
record - Anonymous records
mmorph - Monad morphisms
lens-tutorial - The missing tutorial module for the lens library
managed - A monad for managed values
rio-orphans - A standard library for Haskell
exceptional - A simple Haskell type for pure code that could go wrong.
monad-time
layers - Modular type class machinery for monad transformer stacks.