<div dir="ltr"><div class="gmail_default"><font face="arial, helvetica, sans-serif">Hi Alejandro,</font></div><div class="gmail_default"><font face="arial, helvetica, sans-serif"><br></font></div><div class="gmail_default">
<font face="arial, helvetica, sans-serif">I suspect that "baking algebraic laws" means "getting monad laws for free".</font></div><div class="gmail_default"><font face="arial, helvetica, sans-serif"><br>
</font></div><div class="gmail_default"><font face="arial, helvetica, sans-serif">There's a talk by Andres Loh [1] in which he explains some approaches to custom EDSLs in Haskell, namely, using GADTs and free monads. The former is actually what `operational` implements and the latter is the `free` package.</font></div>
<div class="gmail_default"><br></div><div class="gmail_default"><font face="arial, helvetica, sans-serif">[1] <a href="http://skillsmatter.com/podcast/home/monads-for-free/te-8320">http://skillsmatter.com/podcast/home/monads-for-free/te-8320</a></font></div>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">2013/11/27 Alejandro Serrano Mena <span dir="ltr"><<a href="mailto:trupill@gmail.com" target="_blank">trupill@gmail.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<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><div class="im"><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


<div><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></div><br></div>
<br>_______________________________________________<br>
Haskell-Cafe mailing list<br>
<a href="mailto:Haskell-Cafe@haskell.org">Haskell-Cafe@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/haskell-cafe" target="_blank">http://www.haskell.org/mailman/listinfo/haskell-cafe</a><br>
<br></blockquote></div><br></div>