Examples of Haskell Type Errors

[Tikhon]

I’m working on a blog post about debugging Haskell type errors for beginners and I’m looking for some realistic examples.

I’d appreciate any interesting examples, but especially:

• examples from open source code, or where you can share all the /relevant/ code
• type errors that were not immediately obvious or even actively tricky to fix
  • especially if they were hard to /localize/ (that is, the error message pointed in the wrong place)
• the code involved is reasonably accessible
  • “normal” code rather than intense type-level stuff
  • dealing with some domain that’s not too intimidating

I’d appreciate some run-of-the-mill errors as much as some especially tricky ones.

Even if a type error doesn’t fit my blog post, it will still give me a better idea about what sort of errors people are running into. Who knows, it might turn into a more advanced blog post or even some sort of tooling improvements in the future. (No promises though, I am super flaky on side projects like this )

Thanks in advance!

[Bodigrim]

Is Issues · haskell/error-messages · GitHub of any help?

[Tikhon]

That’s a great resource, but it seems to mostly be around weirder errors and error messages.

I’m looking for more standard type errors in context, especially if they are tricky to localize (ie the error points to one place, but you end up needing to change something different to fix it).

[f-a]

How beginners are the beginners you are writing the article for?

Do you consider “Ambiguous type variable” valid errors? In my experience they bite me a lot when I am using a parser combinator library.

---

Something straight out of the repl:

λ> foldr (+) 0 1

<interactive>:9:1: error: [GHC-39999]
    • Could not deduce ‘Foldable t0’
      from the context: (Foldable t, Num b, Num (t b))
        bound by the inferred type for ‘it’:
                   forall {t :: * -> *} {b}. (Foldable t, Num b, Num (t b)) => b
        at <interactive>:9:1-13
      The type variable ‘t0’ is ambiguous
      Potentially matching instances:
        instance Foldable (Either a) -- Defined in ‘Data.Foldable’
        instance Foldable Maybe -- Defined in ‘Data.Foldable’
        ...plus three others
        ...plus 26 instances involving out-of-scope types
        (use -fprint-potential-instances to see them all)
    • In the ambiguity check for the inferred type for ‘it’
      To defer the ambiguity check to use sites, enable AllowAmbiguousTypes
      When checking the inferred type
        it :: forall {t :: * -> *} {b}. (Foldable t, Num b, Num (t b)) => b

which is a lot of output for “you forgot square brackets”.

[f-a]

Another one by me:

Ambiguous types problem

Hello. Here I come with a question on type ambiguity. I typed it out in code to make it easier to follow and to paste it in your editor if you want to experiment with it. It might seem silly, but now and then I find myself with these problems: for sure you can work around them (in this case by writing two functions), but it would be nice to know how to have the compiler accept those. Thanks in advance for any help! {-# Language RankNTypes #-} {-# Language AllowAmbiguousTypes #-} module Prova …

[Tikhon]

Yeah, that’s a good level, and I might use that as an example for how to parse visually confusing error messages. There’s a lot of noise there!

[atravers]

Slides 28-31 of this presentation:

Why is Haskell so hard! (And how to deal with it?)

…may also be of interest.

[jackdk]

Two classics that I think are worth touching on:

• Beginners will encounter all sorts of errors involving a Foldable constraint before they’ve had a chance to grapple with the monomorphic list functions.
• It’s very easy to use numeric literals in ways that generate confusing error messages:

$ ghci 
GHCi, version 9.6.5: https://www.haskell.org/ghc/  :? for help
ghci> 1 + True

<interactive>:1:1: error: [GHC-39999]
    • No instance for ‘Num Bool’ arising from the literal ‘1’
    • In the first argument of ‘(+)’, namely ‘1’
      In the expression: 1 + True
      In an equation for ‘it’: it = 1 + True

That is not a helpful way to say “numbers are not booleans”. I know why it is so, but a beginner does not. It used to be worse on older GHCs, where an errant numeric literal could conjure up all sorts of errors about FlexibleContexts being disabled.

[DavidB]

We wrote a paper a while ago on localizing the source of type errors (https://dl.acm.org/doi/10.1145/3622812) and also conducted a user study. Most of the type error literature uses OCaml examples of faulty programs, but they can be easily adapted to Haskell since they only use the common Hindley-Milner subset. For example, the authors of https://dl.acm.org/doi/10.1145/3138818 shared their dataset of examples that we also used in our paper. But one of the best starting points is the great survey article https://dl.acm.org/doi/10.1145/3344429.3372508 which contains almost 220 references!

[danidiaz]

I wonder if a package that defined lots of bogus instances with Unsatisfiable preconditions could be helpful for beginners.

Something like

instead of

Instances for IO and functions could be particularly helpful I think.

[tonyalaribe]

This sounds really useful and helpful!

[tomjaguarpaw]

[EDIT: Oh, I said what @danidiaz had already said! Examples of Haskell Type Errors - #10 by danidiaz]

Although, I wouldn’t say it should be “a package”, I would say it should be base.

[jackdk]

Unsatisfiable is a good start, but if we had apartness constraints we could do some of the stuff in this 2017 talk from Compose Melbourne about bringing domain-specific error messages into libraries. The “you haven’t got your monad licence” example is probably the most beginner-relevant.

[Vlix]

I recently had one of these in our production code.

I unfortunately don’t remember how to make it happen again, but I believe it was cause by adding an argument to the type signature of a function that uses do notation, but forgetting to add the argument on the value level (before the =)
(or I did both, but then when reverting my changes forgot to remove the argument from the type signature, which results in the same situation)

Because the do notation was our own monad, and some return values were List/Maybe/etc. and I think the value I added also had Maybe, the do notation was now implicitly confusiing which Monad was used where and I kept juggling with Justs and whatnot, but adding one just made the error weirder (adding expected (Maybe a), but found Maybe (Maybe a) etc. where it was expected a, but found (Maybe a) before I added the Just)

Sorry for being vague, but maybe someone knows how to elicit this situation

[atravers]

I unfortunately don’t remember how to make it happen again, but I believe it was cause by adding an argument to the type signature of a function that uses do notation, but forgetting to add the argument on the value level (before the =)

Perhaps that was due to (->) r being monadic?

# ghci
GHCi, version 9.8.2: https://www.haskell.org/ghc/  :? for help
ghci> :i (->)
type (->) :: * -> * -> *
type (->) = FUN Many :: * -> * -> *
  	-- Defined in ‘GHC.Types’
infixr -1 ->
instance Monoid b => Monoid (a -> b) -- Defined in ‘GHC.Base’
instance Semigroup b => Semigroup (a -> b) -- Defined in ‘GHC.Base’
instance Applicative ((->) r) -- Defined in ‘GHC.Base’
instance Functor ((->) r) -- Defined in ‘GHC.Base’
instance Monad ((->) r) -- Defined in ‘GHC.Base’
ghci>

[Vlix]

You’d think, but any mention of function weirdness would trigger me to think “oh did I screw up the arguments”.
It was exactly because it didn’t mention any of that that it took me a while to figure it out.

Now it might be that one of the monadic things happening in the function was inferred as being the function monad, but with all the potential monadic happenings, it sort of dislocated which part was which monad.
I think I finally figured it out by adding type annotations one by one to check which parts were which monad, and if they were what I expected them to be.

[olf]

Seems no one has mentioned the Haskell error index yet. Probably because type errors do not feature there much. However, the index aims to provide examples like this one.
Perhaps the contents of your blog post eventually can help to update the error index examples.

A particularly hard-to-spot error (at least for me) were the effects of simplified subsumption, which was introduced in GHC 9 and can lead to very strange and cryptic error messages when higher-rank types (e.g. lenses) are involved.

[olf]

@Tikhon

That’s a great resource, but it seems to mostly be around weirder errors and error messages.

But there are also very common issues that can easily bite beginners, e.g. missing ScopedTypeVariables. The nasty bit is that adding a type signature makes things worse while we keep telling beginners that type signatures are helpful.

[Tikhon]

Lovely example, I wouldn’t have thought of that edge case myself.

[stevenxl]

Looking forward to this blog post!