Opened 18 months ago

Closed 18 months ago

Last modified 12 months 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 Revisions:

Description

http://www.haskell.org/ghc/docs/7.6.3/html/users_guide/other-type-extensions.html#implicit-parameters 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 18 months 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
little.

comment:2 Changed 18 months ago by simonpj

  • Status changed from new to merge

Quite right. The user manual is right! Fixed.

I guess it's worth merging this if poss

Simon

comment:3 Changed 18 months ago by thoughtpolice

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

Merged.

comment:4 Changed 18 months ago by andreas.abel

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

comment:5 Changed 12 months 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.