[Haskell-cafe] Algebraic Effects?
zemyla at gmail.com
Wed Sep 19 02:56:17 UTC 2018
The only monads with distributive laws are in Data.Distributive, and
they're all isomorphic to (->) e for some e. So that's effectively
On Tue, Sep 18, 2018 at 5:06 AM, Till Mossakowski <till at iks.cs.ovgu.de> wrote:
> Have distributive laws  ever been used for monad composition in
> Haskell? After all, two monads with a distributive law compose.
>  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 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.
> 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