[Haskell-cafe] Algebraic Effects?

[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.