1. In SystemFC a case branch binds three sorts of variables: type variables
(for the existential types of the relevant DataCon), coercion variables
(similar), and value variables (for the fields of the DataCon).
CoreSyn.AltCon includes a list of Var's -- I assume this is only the
value variables, and that the type/coercion variables come from
DataCon.{dataConExTyVars,dcEqSpec}, right?
This seems to imply that when you have nested cases, you can't avoid
shadowing, since the Var's are the same for every instance of Case:
data Foo = Bar ...
x, y :: Foo
case x of
| Bar ->
case y of
| Bar -> {- HERE -}
so at the program point marked {- HERE -}, any coercions arising from
the case branch on x would be shadowed, and therefore inaccessible.
Is this correct? If those coercions are needed, is one supposed to
use a coercion-lambda to give it a new name?
2. Is there a dummy value variable (i.e., Var.Var) I can use in places
where CoreSyn demands a binder but I know that the variable being
bound will never be referenced? Sort of like mkWildCoVar, but for
values rather than coercions.
3. Case branches are supposed to be sorted in a particular order. Is
there a handy method lying around somewhere to sort an unsorted list
of branches? I couldn't find one, but I can just write my own.
4. I'm a bit confused by this comment in DataCon.lhs:
-- In general, the dcUnivTyVars are NOT NECESSARILY THE SAME AS THE
TYVARS
-- FOR THE PARENT TyCon. With GADTs the data con might not even have
-- the same number of type variables.
-- [This is a change (Oct05): previously, vanilla datacons guaranteed to
-- have the same type variables as their parent TyCon, but that seems
ugly.]
Hrm, how can this be? I thought SystemFC mandated that each datacon
(K) have the same number of *universal* tyvars as its tycon (but, of
course, any number of existential tyvars). Did I miss something here?
_______________________________________________
Cvs-ghc mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/cvs-ghc
