[Haskell-cafe] Algebraic Effects?
till at iks.cs.ovgu.de
Tue Sep 18 10:06:07 UTC 2018
Have distributive laws  ever been used for monad composition in
Haskell? After all, two monads with a distributive law compose.
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 or “freer” monads. 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.
> 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:
> 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.
> : http://okmij.org/ftp/Haskell/extensible/exteff.pdf
> : http://okmij.org/ftp/Haskell/extensible/more.pdf
> : https://twitter.com/rob_rix/status/1034860773808459777
> : 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:
>> 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.
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> Only members subscribed via the mailman list are allowed to post.
More information about the Haskell-Cafe