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

[Alejandro Serrano Mena]

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>