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
Cvs-ghc@haskell.org
http://www.haskell.org/mailman/listinfo/cvs-ghc

Reply via email to