type families not advertised for 6.8
g9ks157k at acme.softbase.org
Fri Oct 19 07:03:22 EDT 2007
Am Freitag, 19. Oktober 2007 11:32 schrieben Sie:
> | In fact, after thinking and experimenting I came to the conclusion that
> | it’s probably just not possible to define a type function TypeEqTF t1 t2
> | which for *all* types t1 and t2 yields True or False, depending on
> | whether t1 and t2 are equal or not.
> That's a nice crisp example. It's a pure function, at the level of types,
> so you'd think it should be definable. And I don't think there is any
> reason we couldn't do so (in due course). For example, overlap is fine,
> so long as when we *use* an equation there is only one that applies, so
> that there is a unique answer.
But the problem in the HList example is that two equations apply where the
most specific one should be taken.
> (Oh, it's just possible that HList might be architected differently if type
> functions were available.)
Yes, but as soon as you start to implement records where field names are
types, you have to have a compile-time type equality check since you need it
for lookup and for making sure that the same field name doesn’t occur twice
in one record. So even if HList would be architectured rather differently,
it would probably still need an equality test.
More information about the Glasgow-haskell-users