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

Ben Franksen wrote:

Or why type Exn

(I meant to write Exc)

but corresponding functions throwError and catchError?

Ah, I just saw that this inconsistency is already fixed, it's Exc consistently in the latest version on hackage. I guess Exc has been chosen to avoid collisions when importing the library unqualified? Cheers Ben -- "Make it so they have to reboot after every typo." -- Scott Adams

On 11/28/2013 10:30 AM, oleg@okmij.org wrote:

Most of the new development is writing more examples and more and better explanations. Recently, for example, I added committed choice (in Prolog terms, soft-cut) to the Choice effect. I was surprised how easy it was and how nothing had to be changed. I merely added a new handler. So, we get another implementation of LogicT, this time in terms of extensible effects.

This sounds very interesting - is this work available for us to look at anywhere? - ocharles

Hi Alejandro, I suspect that "baking algebraic laws" means "getting monad laws for free". There's a talk by Andres Loh [1] in which he explains some approaches to custom EDSLs in Haskell, namely, using GADTs and free monads. The former is actually what `operational` implements and the latter is the `free` package. [1] http://skillsmatter.com/podcast/home/monads-for-free/te-8320 2013/11/27 Alejandro Serrano Mena

Thanks for the pointer! :) The extensible-effects package seems very interesting. I would really like to have instances of all usual monads: Reader, Writer, State.Lazy and so on in the package. Maybe that's a project for the future :)

Even so, I'm still interesting in understanding my original concerns with free vs. operational, specially the "baking algebraic laws" part and whether it's good to replace operational with free-operational altogether.

2013/11/26

...

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 Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

Thanks for both the pointers and the discussion about extensible-effects. I had some time yesterday to look at the paper itself, and I found it really useful and clean. Even though, I still think that porting more monad transformers into extensible-effects could help the latter being used more widely. Right now MTL provides Reader, Writer, State, Cont, Error, RWS; and we have packages for random numbers, or monad-supply for a supply of unique values. I would be willing to use extensible-effects if I knew that I can do all of that within the framework. I still see the possibility of having a nice weekend projects in Haskell :) By the way, I'm also interested in knowing if extensible-effects have some relation to MonadPlus or Applicative in any way. Thanks again for the answers! I really liked the ideas! 2013/11/28

...

The extensible-effects package seems very interesting. I would really like to have instances of all usual monads: Reader, Writer, State.Lazy and so on in the package. Maybe that's a project for the future :)

There is already a Reader and Writer, in Control.Eff.State. I guess Ben Foppa collected them there because they all deal with aspects of State (unlike say, non-determinism or coroutine).

I must stress that thinking of extensible-effects effects as just another implementation of MTL is not productive. Not all effects can be decomposed into State, Reader, etc. layers. Manly, effects should not be decomposed into layers.

The recently discussed Logger was an excellent example. The original poster wondered if Logger is a Writer, or a Reader + IO, or something else. I'd suggest that the answer is that a Logger does a logging effect. One may then think what sort of interaction with the external world executing this logging effect should cause. The original poster thought exactly in these terms and outlined three scenarios. With extensible effects, one implements these scenarios directly.

It seems MTL wrought quite a round-about way of thinking about effects. First we specify the desired interactions with the world and then we start thinking of decomposing them into `usual monads'. Why not to implement the specification directly, without any decomposition?

To make an analogy, it is believed that a mathematical proof can be traced back to ZFC axioms. Yet no mathematician (unless working specifically on foundations) actually thinks of ZFC when doing the proof. [The analogy is imperfect: there are effects that cannot in principle be represented as composition of monad transformer layers.]

On 11/28/2013 12:59 PM, Clark Gaebel wrote:

Reader/Writer/State are handled in extensible-effects inside Control.Eff.State. Cont is handled in Control.Eff.Coroutine (although could use better documentation, patches welcome!). RWS isn't done, but I don't see why it can't be implemented in terms of State! Error is provided by Control.Eff.Exception, and a substitute for monad-supply is provided by Control.Eff.Fresh. Random numbers are in a new package: system-random-effect.

Eff is an instance of applicative, but not MonadPlus. I don't immediately see a way to make it an instance of MonadPlus, especially since we can have an 'IO' effect. And if you do want MonadPlus-like stuff, you just add in the "Choice" effect - right?

- ocharles