Simon Peyton-Jones <simo...@microsoft.com> writes:
> | I assume this is only the
> | value variables, and that the type/coercion variables come from
> | DataCon.{dataConExTyVars,dcEqSpec}, right?
>
> Not so at all. Why did you assume that?
You're right, that was a silly assumption. However, without it, I have
another question:
> The variables bound in a case alternative are the [b] in CoreSyn.Alt.
> These binders include all the type variables, coercion variables, and
> value variables bound in the alternative.
Are there any rules about the order in which the different types of
variables appear (e.g., extyvars first, then covars, then valvars)?
There is a natural order within each of the three sorts dictated by the
DataCon, but I see ambiguity in how those three lists get merged.
> The variables in Datacon.dataConExTyVars are irrelevant.
Hrm, can't they occur in the types of dataConEqTheta like this?
tycon T a
datacon FooT :: forall b. forall c. (EqPred b (list c)) -> T b
I suppose in this example (dataConExTyVars FooT) would be [c], right?
> They are the same in number and kind but not necessarily identity.
Ah, that helps!
> tycon T a b
> datacon MkT :: forall p q. T p q
> the p,q in the MkT might not be identical to the a,b stored in the
> TyCon. Why should they be -- the result is alpha-equivalent
Ah, I see: getTyConTyVars gives you a list of variables bound by the
tycon declaration, whereas dcUnivTyVars tells you how they are
instantiated in the type of a particular datacon.
- a
_______________________________________________
Cvs-ghc mailing list
Cvs-ghc@haskell.org
http://www.haskell.org/mailman/listinfo/cvs-ghc
