[Haskell-cafe] free vs. operational vs. free-operational

[Nickolay Kudasov]

Hi Alejandro,

I suspect that "baking algebraic laws" means "getting monad laws for free".

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.

[1] http://skillsmatter.com/podcast/home/monads-for-free/te-8320


2013/11/27 Alejandro Serrano Mena <trupill at gmail.com>

> 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 at 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 at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20131127/d127a0cd/attachment-0001.html>