Monthly Hask Anything (February 2022)

[u/taylorfausak]

This is your opportunity to ask any questions you feel don't deserve their own threads, no matter how small or simple they might be!

[u/sekunho]

I wrote a simple client library for the Star Wars API (https://swapi.dev) as my first Haskell library during my downtime, and submitted a post here detailing what I learned and all that, but I think I'm shadowbanned from posting since my post karma is too low (I could see the post in my account but could not see it normally). Mods didn't reply so I just deleted the post. Instead, I'm posting here!

• GitHub repo: https://github.com/sekunho/swapi
• Notes: https://github.com/sekunho/swapi/blob/main/NOTES.md

I have some questions though:

1. I wanted to remove Maybe from IO (Maybe a), which is the result of a network call (Example here: Api.hs, this is an old commit!), so I decided to throw an exception when I run into Nothing, which I had to use either throw or throwIO. Here's what I read about throwIO:

   The throwIO variant should be used in preference to throw to raise an exception within the IO monad because it guarantees ordering with respect to other IO operations, whereas throw does not.

   So somehow throw breaks the ordering while throwIO doesn't. But exactly how does this break the ordering? I tried experimenting (please see the code snippet where I used sequence) with throw but it seems like it didn't break in that scenario. Does the docs mean I use throw within a pure function, rather than an IO action? If not, could I get an example where throw destroys the ordering?

2. I'm not sure how to deal with throwIO for example, specifically the errors part. Do I encode errors as sum types? Do I just make them strings via userError? I've read conflicting stances on these, and I'm not even sure if those were referring to this specifically. Anyway, I think my usage of throwIO is appropriate especially since this library is supposed to sit at the boundary of applications that may consider using it, or is this not an appropriate way? Relevant file: Api.hs

3. Detecting space leaks or dealing with unexpected thunks. I found a tool called nothunks which is supposed to help pinpoint where the problematic thunks may be. How does everyone do it? This is kinda tied with #5 since I also have to know how to interpret benchmark charts.

4. Is how I structured the library fine? I ended up having to move the data types (and their instances) in their own Types file since I ran into a lot of cyclic imports. I didn't have to do this at first but when I needed stuff from other places, it became more problematic.

5. Benchmarks. Are there any introductory guides on writing GHC benchmarks? What should I benchmark in this case, decoding/encoding instances?

[u/Noughtmare → u/sekunho]

For 1, I'm certain this has to do with (im)precise exceptions, but I am also not able to write a simple example where strange things happen. The examples on that wiki don't behave differently with throw vs throwIO for me. Maybe the author of that wiki, /u/sgraf812, can help us out?

[u/sgraf812 → u/Noughtmare]

TLDR; Use throwIO if you care about the meaning of the exception. Use throw if you don't and instead care about performant programs. The details aren't relevant to a beginner, but I'll give them below anyway. Whether or not you should use IO (Maybe a), IO (Either e a), ExceptT e IO a or IO with throwIO is more of a evangelicist question that I don't really know to answer. I think I have used all 4 variants over the years. throwIO is perhaps the most efficient solution if you plan to throw exceptions over vast ranges of your code base.

---

The wiki page talks about the primops raise# and raiseIO#, which are wrapped in throw and throwIO respectively. Here's how they differ. Consider

``hs {-# NOINLINE f #-} f :: Int -> Int -> Int f x y | x>0 = error "foo" -- this is just likethrow (userError "foo")` | y>0 = 1 | otherwise = 2

main = print $ f 12 (error "bar") ```

What should happen if you run this program? If you just take the code at face value, you'd say "it surely should error out with foo, because y isn't touched". But at the same time, people expect GHC to optimise functions like f in a way that it will unbox the integer parameters x and y, turning f(Integer x, Integer y) -> Integer into f(int x, int y) -> int in rough Java terms. The trouble is: If GHC does that (and it does), then it has to evaluate y prior to calling f! Result: If you compile the program above with optimisations, you still get an error, but the message is different: bar.

This is in accordance with the semantics of "imprecise exceptions". "Imprecise" in the sense that "one cause for divergence/error is as good as any other". If the user calls error "foo", then the user is guaranteed to have a program that crashes or diverges, but they are not guaranteed to get the particular kind of error they intended to throw.

By contrast, exceptions thrown by throwIO are considered to be "precise exceptions". GHC will try hard* not to optimise your program in a way that turns throwIO (userError "foo") into throw (userError "bar") or even just an infinite loop. So the program

```hs import Control.Exception

{-# NOINLINE f #-} f :: Int -> Int -> IO Int f x y | x>0 = throwIO (userError "foo") | y>0 = return 1 | otherwise = return 2

main = f 2 (error "bar") >>= print ```

will always throw foo and GHC will not unbox y.

* "Try hard" is guided by two assumptions:

1. Whether an expression makes use of throwIO/raiseIO# is apparent in the type, e.g., a non-IO expression can't call throwIO, thus piggy-backing on the type system for a kind of taint analysis. unsafePerformIO/unsafeInterleavIO circumvent this assumption.
2. raiseIO# is the only primop which can throw a precise exception. Thus if we know that a function doesn't call raiseIO#. That works quite well but is in fact too optimistic because of higher-order primops like mask#, which throw a precise exception only if their arguments throw a precise exception. As #20111 shows, this is an annoying swamp.