[Haskell-cafe] Algebraic Effects?

[Vanessa McHale]

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.
>

-- 



*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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20180917/bed41a80/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20180917/bed41a80/attachment.sig>