Opened 3 years ago

Closed 3 years ago

Last modified 3 years ago

#12763 closed bug (fixed)

Incorrect behavior with empty functional dependencies

Reported by: diatchki Owned by:
Priority: normal Milestone: 8.0.2
Component: Compiler (Type checker) Version: 8.0.1
Keywords: FunDeps Cc:
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: None/Unknown Test Case: typecheck/should_compile/T12763
Blocked By: Blocking:
Related Tickets: Differential Rev(s):
Wiki Page:


This is a corner case, but it would appear that GHC doesn't do proper improvements for classes with "empty" functional dependencies. Consider the following example:

class C a | -> a where
   m :: a -> ()

instance C Int

f x = m x

The inferred type for f is C a => a -> (), however I was expecting it to infer Int -> ().

The reasoning is as follows: the use of m generates a C a constraint (a is a unification variable). This should have interacted with the C Int instance (in a rather odd vacuous sort of way) to generate a derived constraint a ~ Int, which should have then instantiated a to Int.

Change History (5)

comment:1 Changed 3 years ago by Simon Peyton Jones <simonpj@…>

In 801c2637/ghc:

Fundeps work even for unary type classes

The functional-dependency improvement functions,
had a side-condition that said the type class has to have at
least two arguments.  But not so, as Trac #12763 shows:

   class C a | -> a where ...

is perfectly legal, albeit a bit of a corner case.

comment:2 Changed 3 years ago by simonpj

Status: newmerge
Test Case: typecheck/should_compile/T12763

Fixed thank you.

comment:3 Changed 3 years ago by simonpj

Milestone: 8.0.2

comment:4 Changed 3 years ago by bgamari

Resolution: fixed
Status: mergeclosed

comment:5 Changed 3 years ago by simonpj

Keywords: FunDeps added
Note: See TracTickets for help on using tickets.