#714: Inconsistency between handling functional dependencies in class and
signature constraints
-------------------------------------+--------------------------------------
Reporter: [EMAIL PROTECTED] | Owner: simonpj
Type: bug | Status: new
Priority: low | Milestone: 6.10 branch
Component: Compiler (Type checker) | Version: 6.5
Severity: normal | Resolution:
Keywords: | Difficulty: Unknown
Testcase: | Architecture: Unknown
Os: Unknown |
-------------------------------------+--------------------------------------
Comment (by claus):
Replying to [comment:11 simonpj]:
> An instance declaration is a bit like a function type signature, but a
class declaration is different. It ''looks'' a bit like a signature, but
it is used the other way round.
That is because superclass context constraints are required earlier than
other context constraints: you cannot even write down a class constraint
unless there are corresponding superclass instances, whereas you can write
down instances and function types with unsatisfied contexts, you just
can't use them if the context constraints can't be satisfied.
So, by the time you have a handle on a class constraint that isn't
outright invalid, you know you've already checked its superclass
constraints, which is why you can use the implication backwards.
> {{{
> class C a b => D a
> }}}
> if (C a b) has a functional dependency. But if so, I'd prefer to write
> {{{
> class C a (F b) => D a
> }}}
The whole point was to bring `b` into scope as functionally dependent on
`C a _`, thereby ''modelling'' a type function in the scope, using the
(class) contexts for type-level "let"-bindings. Which is why the
inconsistent handling of contexts in different locations hurts.
> Let's see if there are examples that give convincing evidence to the
contrary. Perhaps these exist -- Claus describes the problem as acute.
If the patient was in acute trouble 3 years ago, it might not matter now.
As far as I can recall, the discussion was on TF vs FD, and I was trying
to demonstrate that FD, fully implemented, can do everything that TF can.
As I have seen no indication that any other compiler is going to implement
TF, it still seems important to me to have FD supported well.
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/714#comment:13>
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
