#4894: Missing improvement for fun. deps.
----------------------------------------+-----------------------------------
Reporter: diatchki | Owner:
Type: bug | Status: new
Priority: normal | Milestone:
Component: Compiler (Type checker) | Version: 7.1
Keywords: | Testcase:
Blockedby: | Difficulty:
Os: Unknown/Multiple | Blocking:
Architecture: Unknown/Multiple | Failure: None/Unknown
----------------------------------------+-----------------------------------
Comment(by diatchki):
I was thinking that "ByFD" would be a new basic form of evidence in FC,
''defining'' what it means for a predicate to have a FD. As such, it has
no proof in the system but it requires that when we extend the system by
adding new instances, we check that they are consistent with the rules.
The situation is analogous to the super-class check for an instance, and
the consistency check for a type function.
I can see that we can also define what it means for a class to have a FD
in terms of super-classes and type functions. This is probably OK, but I
though I'd write down a few things which seem "a bit off" (not really
problems but things we should watch out for):
* The encoding duplicates information because we have to provide
definitions for both predicates (via class instances) and type functions
(via type family instances), and the type instances are completely derived
from the class ones. This makes programs larger, but also, it forces us
to make some arbitrary choices, as illustrated by the following example:
{{{
instance (F a b, G a b) => C [a] b where ...
-- F, G, and C all have a FD from the 1st argument to the 2nd.
}}}
Here, we can define the FD type function for C either in terms of F or G.
* The encoding introduces a dependency between language features which,
conceptually, seem independent: it makes sense to have a language which
has FDs on classes but no type functions, or even super-classes.
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/4894#comment:4>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
_______________________________________________
Glasgow-haskell-bugs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
