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

[Ben Foppa]

Hi Nick,

Uploader and current maintainer of the extensible-effects package here.
Although I'm still confused myself about the more theoretical bits of 
extensible-effects,
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 
down.

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 
Control.Monad.Fresh<http://hackage.haskell.org/package/tamarin-prover-utils-0.6.0.0/docs/Control-Monad-Fresh.html>, 
as well as Control.Monad.State.Strict<http://hackage.haskell.org/package/mtl-1.1.0.2/docs/Control-Monad-State-Strict.html>
.
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 
interface.
Although the implementations will generally differ from traditional monadic 
implementations,
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>