#3490: Relax superclass restrictions
-------------------------------+--------------------------------------------
Reporter: simonpj | Owner:
Type: bug | Status: new
Priority: normal | Milestone: _|_
Component: Compiler | Version: 6.10.4
Severity: minor | Keywords:
Difficulty: Unknown | Testcase:
Os: Unknown/Multiple | Architecture: Unknown/Multiple
-------------------------------+--------------------------------------------
Doaitse points out that we currently reject
{{{
class C a b | a -> b where
class C a b => D a where
}}}
on the grounds that 'b' is not in scope in the second class decl. (Only
type variables in the "head", namely (D a), can be mentioned in the
superclass context.) My response to him was as follows.
The easiest way forward is to re-express your program using type
functions. Then class C will have just a single type parameter (a), with
the 'b' part being expressed by a type function. That would resolve the
problem rather nicely.
Medium term, I think the Right Thing is to allow a class declaration
{{{
class Q => C a b
}}}
(where Q is a context) if and only iff the type
{{{
forall ab. Q => C a b
}}}
is unambiguous. What does "unambiguous" mean? As it happens, we are
working on nailing that down right now. For example, here is a stupid but
unambiguous declaration:
{{{
type family F a
class (b ~ F a, Eq b) => C a
}}}
I do not know of any non-stupid examples that would be rejected by the
current rule, but there might be some.
I'll open a ticket because I'd like to get to this when we have the other
pieces working.
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3490>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler_______________________________________________
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
