There was an interesting thread on haskell-prime [1], about the relationship
between functional dependencies and type families. This message is my attempt
to summarise the conclusions of that thread. I'm copying other interested
parties (eg Oleg, Dimitrios)
[1] http://www.haskell.org/piperma
On Tue, Jun 14, 2011 at 5:36 AM, Simon Peyton-Jones
wrote:
> There was an interesting thread on haskell-prime [1], about the relationship
> between functional dependencies and type families. This message is my
> attempt to summarise the conclusions of that thread. I'm copying other
> interest
On Tue, Jun 14, 2011 at 4:40 PM, Dan Doel wrote:
> On Tue, Jun 14, 2011 at 5:36 AM, Simon Peyton-Jones
> wrote:
>> There was an interesting thread on haskell-prime [1], about the relationship
>> between functional dependencies and type families. This message is my
>> attempt to summarise the c
At Tue, 14 Jun 2011 09:36:41 +,
Simon Peyton-Jones wrote:
>
> 5. David wants a wiki page fixed. But which one? And how is it "locked
> down"?
This page:
http://hackage.haskell.org/trac/haskell-prime/wiki/FunctionalDependencies
Currently under cons for FunctionalDependencies, it
On Tue, Jun 14, 2011 at 11:27 AM, Andrea Vezzosi wrote:
>> class C a b | a -> b
>> instance C a R
>> instance C T U
>
> Are you sure that worked before?
80%
> The following still does anyhow:
>
> data R
> data T
> data U
> class C a b | a -> b
> instance TypeCast R b => C
At Tue, 14 Jun 2011 10:40:48 -0400,
Dan Doel wrote:
>
> > 1. As things stand in GHC you can do some things with functional
> > dependencies that you can't do with type families. The archetypical example
> > is type equality. We cannot write
> > type family Eq a b :: *
> > type ins
Sorry about the double send, David. I forgot to switch to reply-all in
the gmail interface.
On Tue, Jun 14, 2011 at 11:49 AM,
wrote:
> You absolutely still can use FunctionalDependencies to determine type
> equality in GHC 7. For example, I just verified the code below with
> GHC 7.02:
>
> *Main
On Tue, Jun 14, 2011 at 6:31 PM, Dan Doel wrote:
> Sorry about the double send, David. I forgot to switch to reply-all in
> the gmail interface.
>
> On Tue, Jun 14, 2011 at 11:49 AM,
> wrote:
>> You absolutely still can use FunctionalDependencies to determine type
>> equality in GHC 7. For examp
At Tue, 14 Jun 2011 12:31:47 -0400,
Dan Doel wrote:
>
> Sorry about the double send, David. I forgot to switch to reply-all in
> the gmail interface.
>
> Okay. I don't really write a lot of code like this, so maybe I missed
> the quirks.
>
> In that case, HList has been relying on broken behavio
On Tue, Jun 14, 2011 at 1:19 PM,
wrote:
> No, these are not equivalent. The first one "TypeEq a b c" is just
> declaring an instance that works "forall c". The second is declaring
> multiple instances, which, if there were class methods, could have
> different code. The second one is illegal, b
At Tue, 14 Jun 2011 15:09:02 -0400,
Dan Doel wrote:
>
> On Tue, Jun 14, 2011 at 1:19 PM,
> wrote:
> > No, these are not equivalent. The first one "TypeEq a b c" is just
> > declaring an instance that works "forall c". The second is declaring
> > multiple instances, which, if there were class me
|
http://hackage.haskell.org/trac/haskell-prime/wiki/FunctionalDependencies
|
| Currently under cons for FunctionalDependencies, it says:
|
| AssociatedTypes seem to be more promising.
|
| I proposed the following fix:
|
| AssociatedTypes seem to be more promising, but
Some brief rejoinders.
1. Golly, functional dependencies are tricky aren't they? A big reason I like
type families better is simply that I can understand them.
2. Thank you for correcting my equality example. The code I gave
>class Eq a b c | a b -> c
>instance Eq k k True
On Tue, Jun 14, 2011 at 5:38 PM,
wrote:
> Undecidable instances are orthogonal to both FunctionalDependencies
> and OverlappingInstances. They concern whether or not the compiler
> can guarantee that the typechecker will terminate. You can have
> undecidable instances without either of the other
At Tue, 14 Jun 2011 19:21:38 -0400,
Dan Doel wrote:
>
> If this is really about rules for selecting instances unambiguously
> without any regard to whether some parameters are actually functions
> of other parameters, then the name "functional dependencies" is pretty
> poor.
Maybe "functional dep
I'd like to summarize the relationship between functional dependencies
and type functions, and propose a solution that should get rid of
overlapping instances. The solution does not require messing with
System-FC. In fact, it can be implemented today (although
ungainly). A small bit of GHC support
Dan Doel wrote:
>class C a b | a -> b where
> foo :: a -> b
> foo = error "Yo dawg."
>
>instance C a b where
The instance 'C a b' blatantly violates functional dependency and
should not have been accepted. The fact that it was is a known bug in
GHC. The bug keeps getting mention
17 matches
Mail list logo
