<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<body text="#000000" bgcolor="#FFFFFF">
<p>You can certainly create a new type signature for things that can
fail with <tt>error</tt> or <tt>undefined</tt>, 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.<br>
In the case of the bug you mentioned I'd guess it's just API
stability/the Haskell ecosystem. I believe <tt>error</tt> and <tt>undefined</tt>
are in the Haskell2010 report so I doubt they're going to stop
causing pain anytime soon :)<br>
<div class="moz-cite-prefix">On 09/17/2018 08:15 PM, Viktor Dukhovni
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
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:
<a class="moz-txt-link-freetext" href="https://www.reddit.com/r/haskell/comments/3nkv2a/why_dont_we_use_effect_handlers_as_opposed_to/">https://www.reddit.com/r/haskell/comments/3nkv2a/why_dont_we_use_effect_handlers_as_opposed_to/</a>
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
<div class="moz-signature">-- <br>
style="color:#f00">Functional Compiler Engineer |</span>
<a href="http://iohk.io" style="color:#f00;">www.iohk.io</a></span><br>
Key ID: 4209B7B5</span><br>
Output" height="46" width="200"></a>
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</small></span></div>