<div dir="ltr">Thanks for the pointer! :)<div>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 :)<br>

<div><br></div><div>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.</div>

</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">2013/11/26  <span dir="ltr"><<a href="mailto:oleg@okmij.org" target="_blank">oleg@okmij.org</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class="im"><br>
Alejandro Serrano Mena wrote:<br>
> I really like the separation between providing a data type and then a<br>
> interpretation that operational embodies...<br>
<br>
</div>Then perhaps you may like extensible effects then. They are designed<br>
around the separation of requestors and their interpreters. However, the<br>
set of requests is open (and can be extended at any time without<br>
recompiling the program). Likewise the interpreters can be extended<br>
incrementally. One can add an interpreter for an effect without caring<br>
what other effects are there -- unless one has some reason for caring<br>
about other effects (e.g.,m for finalization). One may then snoop on<br>
other effects while interpreting. Moreover, the handlers may be<br>
scattered around program; they don't have to be all at the very top.<br>
<br>
Crucially, unlike data types a la carte, extensible effects provide<br>
effect encapsulation: one can not only add effects but subtract them,<br>
by completely handling the effects. The type system ensures that all<br>
effects must be completely handled at the end.<br>
<br>
<br>
</blockquote></div><br></div>