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

[Clark Gaebel]

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.

Hope that helps!
  - Clark


On Thu, Nov 28, 2013 at 2:53 AM, Alejandro Serrano Mena
<trupill at gmail.com>wrote:

> 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.]
>>
>>
>>
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>


-- 
Clark.

Key ID     : 0x78099922
Fingerprint: B292 493C 51AE F3AB D016  DD04 E5E3 C36F 5534 F907
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20131128/7285f378/attachment.html>