| 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?
Not so at all. Why did you assume that? 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.
The variables in Datacon.dataConExTyVars are irrelevant.
| 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.
Alas no.
(There is mkWildValBinder, which tries to do what you want, but it is deeply
flawed, and I really want to get rid of it.)
I don't know how to add such a thing without a raft of special cases.
| 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.
I don't think so.
| 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?
They are the same in number and kind but not necessarily identity. Think of
the TyCon and DataCon as separate top-level things. Then from
data T a b = MkT
we might get
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
| 1. SystemFC1 distinguishes between data type constructors (T) and type
| functions (S_n). It seems that in CoreSyn these both become
| TyCon.TyCon -- do I have this right? Is there a way to ask which
| kind of thing a TyCon stands for?
TyCon.isFamilyTyCon. See extensive notes in TyCon
| 2. Type function applications in SystemFC1 are always fully saturated, but
| type constructor applications might not be fully saturated, right?
Correct.
Simon
_______________________________________________
Cvs-ghc mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/cvs-ghc
