[Haskell-cafe] Algebraic Effects?

Tue Sep 18 10:06:07 UTC 2018

Have distributive laws [1] ever been used for monad composition in
Haskell? After all, two monads with a distributive law compose.

Till

[1] https://ncatlab.org/nlab/show/distributive+law

Am 18.09.2018 um 08:06 schrieb Alexis King:
> I think this is a good question. It is one that I investigated in detail
> about a year ago. Here is a brief summary of my findings:
>
>   - Haskell programmers want to compose effects, but they usually
>     express effects with monads (e.g. Reader, State, Except), and monads
>     don’t, in general, compose. Therefore, monad transformers were born.
>     However, monad transformers have a new problem, which is an
>     inability to parameterize a function over the exact set of effects
>     in an overall computation. Therefore, mtl style was born.
>
>   - In recent years, extensible effects libraries have proposed a
>     compelling, less ad-hoc approach to effect composition than mtl
>     style, but mtl style remains by far the most dominant approach to
>     effect composition in Haskell libraries.
>
>   - In Haskell, extensible effects libraries are historically based
>     on either free monads[1] or “freer” monads[2]. The latter approach
>     is newer, provides a nicer API (though that is admittedly
>     subjective), and is faster due to some clever implementation tricks.
>     However, even freer-based EE libraries are significantly slower than
>     mtl style because the way effect handlers are implemented as
>     ordinary functions defeats the inliner in ways mtl style does not.
>
>     That said, this cost is in (>>=), which I find is often (usually?)
>     insignificant compared to other costs, so while mtl spanks EE in
>     microbenchmarks, I did not find a meaningful performance difference
>     between mtl style and freer-based EE in real-world applications.
>
>   - In my personal experience (with an admittedly very small sample
>     size), novice Haskellers find defining new effects with the
>     freer-simple EE library monumentally easier than with mtl style, the
>     latter of which requires a deep understanding of monad transformers,
>     mtl “lifting instances”, and things like newtype deriving or default
>     signatures. (More on freer-simple later.)
>
>   - The ecosystem of EE libraries is a mess. There are
>     extensible-effects, freer, freer-effects, freer-simple, and others.
>     As far as I can tell, extensible-effects is based on free monads,
>     and freer and freer-effects are both unmaintained.
>
> My recommendation: if the performance of using EE is acceptable in your
> application AND you are willing to pay the cost of less ecosystem
> support (which in practice means needing to write adapters to mtl style
> libraries and having access to less documentation), I would strongly
> recommend the freer-simple extensible effect library. MASSIVE
> DISCLAIMER: I am the author and maintainer of freer-simple! However, I
> have a few reasons to believe I am not wholly biased:
>
>   1. I developed freer-simple only after using mtl style in production
>      applications for nearly two years and thoroughly investigating the
>      EE landscape.
>
>   2. I actually compared and contrasted, in practice, the difference
>      in understanding between teaching mtl style, other EE libraries,
>      and freer-simple to Haskell novices.
>
>   3. I have a number of satisfied customers.[3][4]
>
> The distinguishing features of freer-simple are better documentation and
> a dramatically different (and hopefully easier to understand) API for
> defining new effects compared to other extensible effects libraries. For
> details, see the freer-simple module documentation on Hackage here:
>
>   https://hackage.haskell.org/package/freer-simple/docs/Control-Monad-Freer.html
>
> If you have any further questions, I’m happy to answer them, but this
> email is long enough already! Hopefully it isn’t too overwhelming.
>
> Alexis
>
> [1]: http://okmij.org/ftp/Haskell/extensible/exteff.pdf
> [2]: http://okmij.org/ftp/Haskell/extensible/more.pdf
> [3]: https://twitter.com/rob_rix/status/1034860773808459777
> [4]: https://twitter.com/importantshock/status/1035989288708657153
>
>> On Sep 17, 2018, at 20:15, Viktor Dukhovni <ietf-dane at dukhovni.org> wrote:
>>
>>
>> I picked up Haskell fairly recently, as a "better imperative programming
>> language" to implement highly concurrent code to survey DNSSEC and DANE
>> adoption on the Internet.  The results are great, I got a DNS library,
>> network and TLS stack that provide effortless concurrency, and a decent
>> interface to Postgres in the form of the Hasql package and performance
>> is excellent.
>>
>> But I'm still a novice in functional programming, with much to learn.
>> So it is only this week that I've started to read about Algebraic effects,
>> and I curious how the Haskell community views these nowadays.
>>
>> If this is a toxic topic raised by newbies who should just Google
>> past discussions instead, feel free to say so...
>>
>> Does the below thread still sum up the situation:
>>
>>  https://www.reddit.com/r/haskell/comments/3nkv2a/why_dont_we_use_effect_handlers_as_opposed_to/
>>
>> I see Haskell now also has an Eff monad.  Is it widely used?  Efficient?
>> Are there other Haskell libraries that build on it as a foundation?
>>
>> One potential advantage that comes to mind with Effects is that the
>> exceptions raised by a computation can enter its signature and it
>> becomes less likely that a library will leak unexpected exception
>> types from its dependencies to its callers if the expected exceptions
>> are explicit in the signatures and checked by the type system.
>>
>> For example, a while back the Haskell Network.DNS library leaked exceptions
>> from a parser library that was an internal implementation detail, and my code
>> had rare crashes on malformed DNS packets, since I did not expect or handle
>> that exception.
>>
>> -- 
>> 	Viktor.
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.
>