| which leads me to a problem i have with ATs, which applies
| to class aliases as well: although the ATs are written as if they
| were local to the class, they get lifted out of the class in a naive
| manner. in particular, they can only refer to their parameters,
| not to other local definitions/types, and their parameters have
| to match the class parameters.
I'm not sure what you mean here, Claus. Can you give a concrete example?
sure. here's one from practice, even. there was a thread on haskell-cafe
on how to re-export FD-based libraries in AT-based form (for better
match with AT-based client code). the obvious translation of
class FD a b | a -> b
would seem to be
class AT a where type AT a
but, as it turns out, you can't write
instance FD a b => AT a where type AT a = b
because the 'b' is not in scope! from an AT-based perspective,
it ought to be in scope, because the AT definition is local to the
instance, but the AT seems to be implemented as sugar for a
non-local TF, for which the local 'b' is not available (i'm not sure
why there is no lambda-lifting behind the scenes to add that 'b'
parameter, in a hidden form?).
the thread, and Manuel's explanation, are here:
http://www.haskell.org/pipermail/haskell-cafe/2008-March/041168.html
this is likely to be less of a problem for class aliases, because
the component class instances share not only the same form
of instance head, but also the same context (so if a type is
functionally determined by the context in one component, it
is so in all components).
btw, if type family instances could have contexts that functionally
determine extra type parameters, the original poster wouldn't have
to duplicate his FDs as TFs, as suggested in that email, but could
simply write (i think?-):
type instance AT a = FD a b => b
claus
_______________________________________________
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime
