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_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.
-- *Vanessa McHale* Functional Compiler Engineer | Chicago, IL Website: www.iohk.io http://iohk.io Twitter: @vamchale PGP Key ID: 4209B7B5 Input Output http://iohk.io Twitter https://twitter.com/InputOutputHK Github https://github.com/input-output-hk LinkedIn https://www.linkedin.com/company/input-output-global This e-mail and any file transmitted with it are confidential and intended solely for the use of the recipient(s) to whom it is addressed. Dissemination, distribution, and/or copying of the transmission by anyone other than the intended recipient(s) is prohibited. If you have received this transmission in error please notify IOHK immediately and delete it from your system. E-mail transmissions cannot be guaranteed to be secure or error free. We do not accept liability for any loss, damage, or error arising from this transmission