Opened 4 years ago

Last modified 13 months ago

#7624 new bug

Handling ImplicitParams in Instance Declaration

Reported by: philipjf Owned by:
Priority: normal Milestone:
Component: Documentation Version: 7.6.1
Keywords: ImplicitParams Cc:
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: Documentation bug Test Case:
Blocked By: Blocking:
Related Tickets: Differential Rev(s):
Wiki Page:

Description (last modified by simonpj)

The GHC documentation states that ImplicitParam's may not be used in class or instance declaration constraints. see for example In practice though, at least on the Mac, all recent version of GHC have permitted such instances. At the very least the documentation should make clear that the compiler might permit such instances, but they have undefined behaviour. Ideally, these would simply be permitted.

Why I think the (undocumented) current behavior is correct
reddit discussion thereof

Change History (8)

comment:1 Changed 4 years ago by simonpj

difficulty: Unknown

I think the issue is this. Consider this:

class C a where
  op :: a -> a

instance (?x:[a]) => C [a] where 
  op _ = ?x

foo y xs = let ?x = [y]
           in (length xs, op xs)

From the instance declaration we get a dictionary-constructing function with type

dfunCList :: forall a. (?x:a) -> C [a]

What type should be inferred for foo? I can think of three. I give there with their translation into System F so you can see what proof strategy I've used to solve the constraints.

foo1 :: C [a] => b -> [a] -> [a]
foo1 a (d:C [a]) (y:b) (xs:[a])
  = let _x = [y]
    in (length a xs, op a d xs)

foo2 :: (?x:a} => b -> [a] -> [a]
foo2 a b (?x:a) (y:b) (xs:[a])
  = let _x = [y]
    in (length a xs, op a (dfunCList a ?x) xs)

foo3 :: a -> [a] -> [a]
foo3 a (y:a) (xs:[a])
  = let ?x = [y]
    in (length a xs, op a (dfunCList a ?x) xs)

Notice that there is no most-general type. It all depends when we make use of the dfunCList dictionary construction, and, even when we have done so, whether we take advantage of the local binding for ?x. I suppose we could just say "GHC will randomly decide which of these three to pick, but its hardly satisfactory!

Adding implicit parameters as superclasses is at least as problematic, perhaps more so.

In short, I'm unconvinced!


comment:2 Changed 4 years ago by philipjf

Hm... I'm not sure that is different from what happen currently with local evidence and/or implicitParams

{-# LANGUAGE GADTs, ImplicitParams #-}
class C a where
  op :: a -> a

data X a where
  X :: C a => X a

fooGADT X xs = (length xs, op xs)

fooIP xs ys = let ?op = const ys in (length xs, ?op xs)

GHC infers types for both of these terms, and has rules to do it. We have fooGADT :: C [a] => X t -> [a] -> (Int, [a]) inferred, but this type will be rejected if we give it as an annotation because it has a non type variable argument, and is no more general than fooGADT :: X [a] -> [a] -> (Int, [a]).

Actually, giving a type annotation is not good enough in the presence of local type information to determine behavior

fooGADT' :: X [a] -> X [a] -> [a] -> (Int,[a])
fooGADT' X X xs = (length xs, op xs)

or the really unclear

data X' a where
 X' :: (?op :: a -> a) => X' a

fooGADT'' :: X' [a] -> X' [a] -> [a] -> (Int,[a])
fooGADT'' X' X' xs = (length xs, ?op xs)

whatShouldThisDo :: [a] -> [a] -> (Int, [a])
whatShouldThisDo xs ys 
     = let a = (let ?op = const ys in X')
             b = (let ?op = id in X')
         in  fooGADT'' a b xs

The point is, I think this is a general problem, and not one unique to allowing implicits in instances. With orphan instnaces you don't need implicit params at all to make this problem show up.

Allowing implicits in class constraints seems more suspect though.

comment:3 Changed 4 years ago by igloo

Milestone: 7.8.1

comment:4 Changed 4 years ago by simonpj

Description: modified (diff)

comment:5 Changed 3 years ago by thoughtpolice


Moving to 7.10.1

comment:6 Changed 2 years ago by thoughtpolice


Moving to 7.12.1 milestone; if you feel this is an error and should be addressed sooner, please move it back to the 7.10.1 milestone.

comment:7 Changed 18 months ago by thoughtpolice


Milestone renamed

comment:8 Changed 13 months ago by thomie

Milestone: 8.0.1
Note: See TracTickets for help on using tickets.