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 <oleg@okmij.org>

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.

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe