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

Alejandro Serrano Mena trupill at gmail.com
Thu Nov 28 07:53:23 UTC 2013

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 <oleg at okmij.org>

> > 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.]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20131128/70d219f0/attachment.html>

More information about the Haskell-Cafe mailing list