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

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.Freshhttp://hackage.haskell.org/package/tamarin-prover-utils-0.6.0.0/docs/Control..., as well as Control.Monad.State.Stricthttp://hackage.haskell.org/package/mtl-1.1.0.2/docs/Control-Monad-State-Stri... . Clark Gaebel has also created the system-random-effecthttp://hackage.haskell.org/package/system-random-effectpackage 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 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...@haskell.org javascript: http://www.haskell.org/mailman/listinfo/haskell-cafe