Opened 2 years ago

Last modified 5 months ago

#13971 new bug

Misleading "Kind mis-match on LHS of default declaration" error

Reported by: RyanGlScott Owned by:
Priority: normal Milestone:
Component: Compiler (Type checker) Version: 8.0.1
Keywords: TypeFamilies Cc:
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

This program fails to typecheck, unsurprisingly:

{-# LANGUAGE PolyKinds #-}
{-# LANGUAGE TypeFamilies #-}
module Bug where

class C a where
  type T a :: k
  type T a = Int

But the error message it gives threw me for a loop initially:

$ /opt/ghc/8.2.1/bin/ghci Bug.hs
GHCi, version 8.2.0.20170704: http://www.haskell.org/ghc/  :? for help
Loaded GHCi configuration from /home/rgscott/.ghci
[1 of 1] Compiling Bug              ( Bug.hs, interpreted )

Bug.hs:7:3: error:
    • Kind mis-match on LHS of default declaration for ‘T’
    • In the default type instance declaration for ‘T’
      In the class declaration for ‘C’
  |
7 |   type T a = Int
  |   ^^^^^^^^^^^^^^
Failed, 0 modules loaded.

The LHS of the default declaration is perfectly fine - the real source of the error is the RHS!

Change History (4)

comment:1 Changed 12 months ago by RyanGlScott

I suppose we could just remove the phrase "on LHS" as a simple fix.

comment:2 Changed 7 months ago by RyanGlScott

What's curious is that in other situations, the error message you get for mismatched kinds in type family defaults is much clearer. For instance:

λ> class C a where { type T a; type T a = 4 }

<interactive>:1:40: error:
    • Expected a type, but ‘4’ has kind ‘GHC.Types.Nat’
    • In the type ‘4’
      In the default type instance declaration for ‘T’
      In the class declaration for ‘C’

That is much, much better than the vague "Kind mis-match on LHS of default declaration" message we get in the original program. I wonder if GHC can arrange for this "Expected a type, but foo has kind Bar" error message to trigger for the original program as well.

comment:3 Changed 6 months ago by Marge Bot <ben+marge-bot@…>

In 33b0a29/ghc:

Tweak error messages for narrowly-kinded assoc default decls

This program, from #13971, currently has a rather confusing error
message:

```hs
class C a where
  type T a :: k
  type T a = Int
```
```
    • Kind mis-match on LHS of default declaration for ‘T’
    • In the default type instance declaration for ‘T’
      In the class declaration for ‘C’
```

It's not at all obvious why GHC is complaining about the LHS until
you realize that the default, when printed with
`-fprint-explicit-kinds`, is actually `type T @{k} @* a = Int`.
That is to say, the kind of `a` is being instantiated to `Type`,
whereas it ought to be a kind variable. The primary thrust of this
patch is to weak the error message to make this connection
more obvious:

```
    • Illegal argument ‘*’ in:
        ‘type T @{k} @* a = Int’
        The arguments to ‘T’ must all be type variables
    • In the default type instance declaration for ‘T’
      In the class declaration for ‘C’
```

Along the way, I performed some code cleanup suggested by @rae in
https://gitlab.haskell.org/ghc/ghc/issues/13971#note_191287. Before,
we were creating a substitution from the default declaration's type
variables to the type family tycon's type variables by way of
`tcMatchTys`. But this is overkill, since we already know (from the
aforementioned validity checking) that all the arguments in a default
declaration must be type variables anyway. Therefore, creating the
substitution is as simple as using `zipTvSubst`. I took the
opportunity to perform this refactoring while I was in town.

Fixes #13971.

comment:4 Changed 5 months ago by Marge Bot <ben+marge-bot@…>

In 78a5c4ce/ghc:

Check for duplicate variables in associated default equations

A follow-up to !696's, which attempted to clean up the error messages
for ill formed associated type family default equations. The previous
attempt, !696, forgot to account for the possibility of duplicate
kind variable arguments, as in the following example:

```hs
class C (a :: j) where
  type T (a :: j) (b :: k)
  type T (a :: k) (b :: k) = k
```

This patch addresses this shortcoming by adding an additional check
for this. Fixes #13971 (hopefully for good this time).
Note: See TracTickets for help on using tickets.