Re: [Haskell-cafe] Algebraic Effects?

The only monads with distributive laws are in Data.Distributive, and they're all isomorphic to (->) e for some e. So that's effectively ReaderT. On Tue, Sep 18, 2018 at 5:06 AM, Till Mossakowski wrote:

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

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

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.

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