[Haskell-cafe] Algebraic Effects?

[Zemyla]

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 <till at iks.cs.ovgu.de> 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.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.
>>
>
> _______________________________________________
> 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.