Opened 3 years ago

Closed 3 years ago

Last modified 2 years ago

#8912 closed bug (fixed)

Documentation stale: implicit-parameter constraints seem to be allowed in instance declarations now.

Reported by: andreas.abel Owned by:
Priority: normal Milestone:
Component: Documentation Version: 7.6.3
Keywords: implicit-parameter instance-constraints 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 says:

You can't have an implicit parameter in the context of a class or instance declaration. For example, both these declarations are illegal:

  class (?x::Int) => C a where ...
  instance (?x::a) => Foo [a] where ...

However, ghc 7.6.3 seems to accept this now:

  {-# LANGUAGE ImplicitParams #-}

  class C a where
    toInt :: a -> Int

  instance (?imp :: Int) => C [a] where
    toInt _ = ?imp

  test :: Int 
  test = let ?imp = 5 in toInt "Hello, world"

test evaluates to 5.

Change History (5)

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

In a8b7b28cdb98d14c6fb43d5ad3293fd4a5c1f8b4/ghc:

Implicit parameters should not be allowed in class and instance declarations

Trac #8912 pointed out that GHC 7.4 and 7.6 have omitted this test, although
7.2 and earlier had it.  This patch puts the test back in, and refactors a

comment:2 Changed 3 years ago by simonpj

Status: newmerge

Quite right. The user manual is right! Fixed.

I guess it's worth merging this if poss


comment:3 Changed 3 years ago by thoughtpolice

Resolution: fixed
Status: mergeclosed


comment:4 Changed 3 years ago by andreas.abel

Ah, too bad, I thought this feature had been implemented. Seemed to work, though. Cheers, A

comment:5 Changed 2 years ago by dimitris

But it's a useful feature, although arguably a bit dangerous to use ...

For instance I am working with a library that someone else has written that exposes only a type-class based interface, i.e. you provide instances of certain classes. Now these classes provide -- sadly -- only a functional interface, so the only way for me to parameterize my instance implementation is to use a class instance context. But if that context can't itself be an implicit parameter or its instances depend on an implicit parameter then it's pretty impossible to reconfigure my code! So I think there is a pretty compelling case to /omit/ that check and perhaps warn users that this may lead to unpredictable behaviour.

Note: See TracTickets for help on using tickets.