Opened 2 years ago

Last modified 11 months ago

#14319 new bug

Stuck type families can lead to lousy error messages

Reported by: dfeuer Owned by:
Priority: normal Milestone: 8.10.1
Component: Compiler (Type checker) Version: 8.3
Keywords: TypeInType, TypeFamilies Cc: goldfire
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: Poor/confusing error message Test Case:
Blocked By: Blocking:
Related Tickets: Differential Rev(s):
Wiki Page:

Description (last modified by dfeuer)

I first noticed this problem at the type level:

{-# language TypeFamilies, TypeInType, ScopedTypeVariables #-}

module ArityError where
import Data.Kind
import GHC.TypeLits
import Data.Proxy

type family F (s :: Symbol) :: Type
type family G (s :: Symbol) :: F s
type instance G "Hi" = Maybe

This produces the error message

ArityError.hs:10:24: error:
     Expecting one more argument to Maybe
      Expected kind F "Hi", but Maybe has kind * -> *
     In the type Maybe
      In the type instance declaration for G
10 | type instance G "Hi" = Maybe
   |                        ^^^^^

This looks utterly bogus: F "Hi" is stuck, so we have no idea what arity it indicates.

I just realized we have a similar problem at the term level:

f :: forall (s :: Symbol). Proxy s -> F s
f _ _ = undefined


ArityError.hs:14:1: error:
     Couldn't match expected type F s with actual type p0 -> a0
      The type variables p0, a0 are ambiguous
     The equation(s) for f have two arguments,
      but its type Proxy s -> F s has only one
     Relevant bindings include
        f :: Proxy s -> F s (bound at ArityError.hs:14:1)
14 | f _ _ = undefined
   | ^^^^^^^^^^^^^^^^^

The claim that Proxy s -> F s has only one argument is bogus; we only know that it has at least one argument. The fix (I imagine) is to refrain from reporting arity errors when we don't know enough about the relevant arities.

Change History (8)

comment:1 Changed 2 years ago by dfeuer

This comment has been edited into the ticket description.

Last edited 2 years ago by dfeuer (previous) (diff)

comment:2 Changed 2 years ago by dfeuer

Description: modified (diff)
Summary: Stuck kind families can lead to lousy error messagesStuck type families can lead to lousy error messages

comment:3 Changed 2 years ago by goldfire

While I agree that these error messages are perhaps misleading, I argue that we should protect the common case from erosion. What I mean here is that the vast majority of these kinds of errors are, I'm sure, places where arities are known, and I would want to continue to report those. I would even want to do this if, sometimes, an error message is a bit wrong -- the cognoscenti that write the code leading to the error messages will know better, anyway.

comment:4 Changed 2 years ago by dfeuer

How hard would it be to report an arity error only when we know the arity is wrong? And how often do we not know for sure? I don't want erosion of the common case either, but I don't see why it would be likely here.

comment:5 Changed 22 months ago by bgamari


This ticket won't be resolved in 8.4; remilestoning for 8.6. Do holler if you are affected by this or would otherwise like to work on it.

comment:6 Changed 17 months ago by bgamari


comment:7 Changed 17 months ago by bgamari

These won't be addressed in GHC 8.6.

comment:8 Changed 11 months ago by osa1


Bumping milestones of low-priority tickets.

Note: See TracTickets for help on using tickets.