Re: [Haskell-cafe] Algebraic Effects?

On Sep 17, 2018, at 10:57 PM, Vanessa McHale wrote:

You can certainly create a new type signature for things that can fail with error or undefined, but keep in mind that the *real* logical bottom, viz. infinite recursion, is still there. I know that Idris and ATS both have some mechanism for checking for non-termination (and in the case of ATS, it is dealt with as an algebraic effect I believe), but GHC would not truly be able to eliminate bottoms without writing an extension yourself.

Given the novelty (to me) of Algebraic Effects, my question was intended to be broader than just whether they could help expose exception signatures. Are they likely to play a larger role in Haskell? Are they sufficiently simpler to reason about or use than monads to warrant thinking in terms of Effects instead in some/many cases?

In the case of the bug you mentioned I'd guess it's just API stability/the Haskell ecosystem. I believe error and undefined are in the Haskell2010 report so I doubt they're going to stop causing pain anytime soon :)

Yes, of course, but I would still like to see libraries convert exceptions in underlying dependencies to something that might make sense to the caller of the library. Thus, (with no prejudice against the Network.DNS library, it just happens a core library in my project) I'd have expected the DNS library to return a some DNS-specific exception (malformed packet, ...) rather than an error from Attoparsec. And indeed this has been addressed. So that was just one possible advantage, but it seems the real win is supposed to be the ability to construct and compose lots of seemingly different primitives out of Effects (generators, concurrency, exceptions, state, ...). And so I am curious whether Haskell is likely some day to adopt and use Effects in some essential way, or whether they will remain a feature of peripheral libraries. Effects appear to be marketed as simpler to learn/use and to offer greater modularity than monads and monad transformers. Do they deliver on these promises, especially in larger projects? -- Viktor.