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, as well as Control.Monad.State.Strict.
Clark Gaebel has also created the 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...@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
Haskel...@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe