[Haskell-cafe] free vs. operational vs. free-operational
benjamin.foppa at gmail.com
Tue Nov 26 22:30:18 UTC 2013
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
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-220.127.116.11/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
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,
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,
>> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Haskell-Cafe