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

Ben Foppa benjamin.foppa at gmail.com
Tue Nov 26 22:30:18 UTC 2013

Hi Nick,

Uploader and current maintainer of the extensible-effects package here.
Although I'm still confused myself about the more theoretical bits of 
I think I might be able to shed some light on it from a user's and 
maintainer's perspective.

extensible-effects is currently operational, and works quite well wherever 
I use it.
That said, it's a new package and I'd expect some shifts before it settles 

In general, extensible-effects seems to be applicable in most cases where 
one might think "hey, I should make a Monad for this".
The base extensible-effects package includes "translations" of 
as well as Control.Monad.State.Strict<http://hackage.haskell.org/package/mtl->
Clark Gaebel has also created the system-random-effect<http://hackage.haskell.org/package/system-random-effect>package for (pure) random number generation via the extensible-effects 
Although the implementations will generally differ from traditional monadic 
the usage is remarkably similar (by far the most common use I've had of 
extensible-effects is using do-notation).

Hope this helps,
Ben Foppa

On Tuesday, 26 November 2013 07:20:15 UTC-5, Nickolay Kudasov wrote:
> Hi Oleg,
> These extensible effects are great, thank you for bringing them up!
> However it seems that the code is still under early development.
> Could you please elaborate on the current state of the project?
> Can it be considered stable?
> Where should I look for the uses of extensible effects?
> Thanks in advance,
> Nick
> 2013/11/26 <ol... at okmij.org <javascript:>>
>> 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
>> Haskel... at haskell.org <javascript:>
>> http://www.haskell.org/mailman/listinfo/haskell-cafe
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20131126/506c0792/attachment.html>

More information about the Haskell-Cafe mailing list