Thanks for the pointer! :)
The extensible-effects package seems very interesting. I would really like
to have instances of all usual monads: Reader, Writer, State.Lazy and so on
in the package. Maybe that's a project for the future :)
Even so, I'm still interesting in understanding my original concerns with
free vs. operational, specially the "baking algebraic laws" part and
whether it's good to replace operational with free-operational altogether.
2013/11/26
Alejandro Serrano Mena wrote:
I really like the separation between providing a data type and then a interpretation that operational embodies...
Then perhaps you may like extensible effects then. They are designed around the separation of requestors and their interpreters. However, the set of requests is open (and can be extended at any time without recompiling the program). Likewise the interpreters can be extended incrementally. One can add an interpreter for an effect without caring what other effects are there -- unless one has some reason for caring about other effects (e.g.,m for finalization). One may then snoop on other effects while interpreting. Moreover, the handlers may be scattered around program; they don't have to be all at the very top.
Crucially, unlike data types a la carte, extensible effects provide effect encapsulation: one can not only add effects but subtract them, by completely handling the effects. The type system ensures that all effects must be completely handled at the end.