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.
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 :)
On 09/17/2018 08:15 PM, 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_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.
