## #1207 closed bug (wontfix)

# Unnecessary prohibition of unquantified higher-order typeclass constraints

Reported by: | Owned by: | ||
---|---|---|---|

Priority: | low | Milestone: | |

Component: | Compiler (Type checker) | Version: | 6.6 |

Keywords: | Cc: | ||

Operating System: | Unknown/Multiple | Architecture: | Unknown/Multiple |

Type of failure: | None/Unknown | Test Case: | |

Blocked By: | Blocking: | ||

Related Tickets: | Differential Rev(s): | ||

Wiki Page: |

### Description

In GHC 6.6, attempting to declare a function (say f) with a type of the form

forall t. ... -> (Num t => ...) -> ...

produces the error:

All of the type variables in the constraint `Num t' are already in scope (at least one must be universally quantified here)

This used to make sense -- after all, there's no way f can deduce a Num constraint on t that wasn't provided by its caller, so a higher-order argument with this sort of type is uncallable. But with the addition of GADTs, this is no longer true, since another of f's arguments might, when deconstructed, reveal that t is in fact an Int or a Ratio u. In fact, GADT deconstructors can have types like this. E.g.

data Foo a where Bar :: forall a. Num a => a -> Foo a

has a deconstructor of type

forall a r. Foo a -> (Num a => a -> r) -> r

So I think that these types should be allowed, although I haven't found a use for them yet except for writing GADT deconstructors.

On the other hand, one can't write deconstructors for most GADTs even with this change, so perhaps it's the wrong change. If explicit type equality constraints were allowed in Haskell, then I could write

forall t. ... -> (forall t'. (t ~ t', Num t') => ...) -> ...

instead.

### Change History (3)

### comment:1 Changed 10 years ago by

Resolution: | → wontfix |
---|---|

Status: | new → closed |

### comment:2 Changed 9 years ago by

Architecture: | Multiple → Unknown/Multiple |
---|

### comment:3 Changed 9 years ago by

Operating System: | Multiple → Unknown/Multiple |
---|

**Note:**See TracTickets for help on using tickets.

Types like this are allowed in the HEAD, as a result of a recent and non-trivial enhancement to type inference I added, called "implication constraints". There is no chance this is going to change in 6.6 though, I'm afraid.

So it's "won't fix" for 6.6 and "already fixed" for the HEAD!

Simon