Opened 3 years ago

Closed 3 years ago

Last modified 3 years ago

#5481 closed bug (fixed)

Associated type defaults + MultiParamTypeClasses error

Reported by: illissius Owned by:
Priority: normal Milestone:
Component: Compiler Version: 7.3
Keywords: Cc:
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: GHC rejects valid program Difficulty:
Test Case: Blocked By:
Blocking: Related Tickets:

Description

If I try this with GHC HEAD as of yesterday:

{-# LANGUAGE TypeFamilies, MultiParamTypeClasses #-}

class Foo a b where
    type X a
    type X a = b
    type Y b
    type Y b = a

I get this error:

test2.hs:7:5:
    Type indexes must match class instance head
    Found `b' but expected `a'
    In the type synonym instance declaration for `Y'
    In the class declaration for `Foo'

Notably, it doesn't complain about type X a = b, only type Y b = a. Unless I'm doing something dumb, it should probably work both ways.

Change History (7)

comment:1 Changed 3 years ago by batterseapower

Oops. The consistent instantiation check was totally broken. Validating a fix now.

comment:2 Changed 3 years ago by batterseapower@…

commit 7ca27dce4943ae3b99dd97d1cb5d51863a9a8b02

Author: Max Bolingbroke <batterseapower@hotmail.com>
Date:   Sun Sep 11 17:09:31 2011 +0100

    Fix associated type default instantiation check (#5481)

 compiler/typecheck/TcTyClsDecls.lhs |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

comment:3 Changed 3 years ago by batterseapower

  • Resolution set to fixed
  • Status changed from new to closed

comment:4 Changed 3 years ago by simonpj

No, it should work neither way! In any type instance, whether associated or not, the variables mentioned on the RHS must be a subset of those on the LHS. So the above code should fail with

T5481.hs:6:5:
    The RHS of an associated type declaration mentions type variable `b'
      All such variables must be bound on the LHS

T5481.hs:8:5:
    The RHS of an associated type declaration mentions type variable `a'
      All such variables must be bound on the LHS

Simon

comment:5 Changed 3 years ago by illissius

Hmm. Intuitively, though, taking the original example:

class Foo a b where
    type X a
    type X a = b
    type Y b
    type Y b = a

The default associated types aren't actual type family instance declarations, otherwise they'd result in overlap every time a specific instance chose a different RHS from the default. The defaults only get instantiated (if that's the right terminology) when an instance for the class is actually declared.

So if I write

instance Foo Int Char

what that really means is

instance Foo Int Char where
    type X Int = Char
    type Y Char = Int

No type variables on the RHS!

There'd be nothing at all preventing me from writing that manually, or from writing it the same way at the top level with non-associated type families. It'd merely be longer.

Am I wrong?

comment:6 Changed 3 years ago by simonpj

But if you said

instance Foo [a] [b] 

you'd generate the bogus instance

instance Foo [a] [b] where
  type X [a] = [b]
  type Y [b] = [a]

I think that defaults should always generate correct code. At lesat that's the conservative choice.

Simon

comment:7 Changed 3 years ago by illissius

Good point.

Note: See TracTickets for help on using tickets.