#2247: GHC accepts FD violations, unless the conflicing instances are used
-------------------------------------+--------------------------------------
Reporter: claus | Owner:
Type: bug | Status: reopened
Priority: normal | Milestone:
Component: Compiler (Type checker) | Version: 6.9
Severity: normal | Resolution:
Keywords: TF vs FD | Difficulty: Unknown
Testcase: | Architecture: Unknown
Os: Unknown |
-------------------------------------+--------------------------------------
Changes (by claus):
* status: closed => reopened
* resolution: duplicate =>
Comment:
Replying to [comment:2 simonpj]:
> I assume you are using some flags?
always!-) in fact, as you can see from this little example, using GHC has
become very inconvenient due to the proliferation of flags. first, i have
to iterate to figure out which flags i need to get my code accepted. then,
i have to do the same again because the GHCi session does *not* inherit
the `LANGUAGE` pragmas from the module i load..
it doesn't help that `UndecidableInstances` is needed so often for
perfectly decidable code. in this case, delegating to another constraint
that is no smaller than the original already requires this extension,
independent of coverage.
> In fact to get `Improve` to compile you need
> {{{
> $gpj -c -XFunctionalDependencies
> -XMultiParamTypeClasses
> -XFlexibleInstances
> -fallow-undecidable-instances
> -XFlexibleContexts
> Foo.hs
> }}}
> The offending one is `-fallow-undecidable-instances`, and this ticket is
an excellent example of #1241. Currently saying `-fallow-undecidable-
instances` lifts the coverage condition. I acknowledge that this isn't the
Right Thing in #1241, but it doesn't threaten type soundness (ie programs
will not seg-fault).
>
> So I'm going to close this bug and link to it from #1241. Re-open if I
have misunderstood.
yes and no. yes, for the current implementation of FDs in GHC; no, in
principle.
neither coverage nor fullness appear necessary for confluence (cf.
[http://www.cs.kuleuven.be/~toms/Research/papers/tfp08-full.pdf Restoring
Confluence for Functional Dependencies, T. Schrijvers, M. Sulzmann]), and
a confluent implementation of FDs should raise all inconsistencies, with
the exception of dead code (the ticket example was meant to highlight this
gap, see also the discussion of forward inference in
http://www.haskell.org/pipermail/haskell-cafe/2008-April/042219.html).
the variation shows clearly that GHC drops FD/improvement-related
information, so that not even all conflicts in live constraints are
flagged. it seems that one of the places where improvement-related
information is dropped is separate compilation (if all FD-relevant
constraints were cached as they arise, and preserved in interface files,
inlining across module boundaries ought to make no difference, right?).
note also this reduced variation
{{{
class FD a b | a -> b
instance CFD a b => FD a b
class FD a b => CFD a b
instance CFD Bool Char
-- instance CFD Bool Bool
}}}
which is accepted by Hugs (in Hugs mode), in spite of its presumably
stricter conditions. yet, on uncommenting the second `CFD` instance, Hugs
notices the FD-inconsistency immediately, while GHCi doesn't (and the
other variations show that GHC won't necessarily notice the issue later,
either).
so, the two tickets are linked, but if one looks beyond ruling out this
kind of example (and #1241 seemed to tend in the direction of finding less
restrictive conditions than GHC has, not more restrictive conditions than
Hugs has), there seems to be more going on. at the very least, this ticket
should be looked into when #1241 gets fixed, in case it isn't covered by
the same fix.
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2247#comment:3>
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
