Changes between Version 1 and Version 2 of DataParallel/ClosureConversion/Indexed

Apr 17, 2007 11:55:25 AM (11 years ago)



  • DataParallel/ClosureConversion/Indexed

    v1 v2  
    1717  fr (Clo f e) = f e
     20For all basic types, we want something like the following:
     22instance CC Int where
     23  newtype CConv Int = CCInt Int
     24  to = CCInt
     25  fr (CCInt x) = x
     27In fact, we want something like that for all types that are defined in modules that are not closure-converted.  Unfortunately, associated ''data'' types cannot have defaults.  (Also note that we use here a `newtype instance` for a `data` family.  Something, which should be easy to add to GHC's implementation of associated types, but isn't allowed right now.)
     29=== User-defined types ===
     31When we encounter a data type definition for `T a1 .. an` in a closure converted module, we need to generate a `CC (T a1 .. an)` instance of `CC`.  The right hand side of `CConv (T a1 .. an)` will have the same form as that of `T`, but with all data constructors renamed and with all types `t` replaced by `CConv t`.  If no arrows occur directly or indirectly in the definition of `T`, we could instead use the same ''default'' instance as outlined for basic types above, as an optimisation.
     33=== Import and export ===
     35To export and import the data constructors of `CConv` instances, we can just export and import `CConv(..)`.
     37=== Higher-kinded types ===
     39During our brain storming, we thought that we might need `CConv` on higher-kinds, too - i.e., if we have `CConv (T a1 .. an)`, we also want `CConv T`.  The idea was that if we have
     41data U t = forall a. U a (a -> t a)
     42data T a = ...
     44the translation of `U T` requires `CConv T`.
     46However, I am not so convinced anymore that we really need it (at least as long as disregarding the interaction with non-closure-converted code).  After all, we need `CConv` essentially in two places:
     47 1. If we have `f :: tau`, we produce `f' :: CConv tau`.
     48 2. If we have `data T = MkT tau`, we produce `data CConv T = CCMkT (CConv tau)`.
     49In both cases, we only apply `CConv` to tau types.  (In GHC's sense of tau types.)
     51The only place, where that's not the case that I can see at the moment is when the closure-converted module defines (or uses?) constructor classes.  Then, we need a corresponding constructor class for `CConv C` (where the `C` is the type constructor).  This doesn't seem to be a feature that we need to cover in the near future.
     53In any case, we might be able to use a family of classes (such as with `Typeable` and we also discussed some tricks we might be able to play with associated synonyms).
     55=== Contexts: 1. dealing with signature contexts ===
     57Something we didn't think about much so far is how to closure convert functions that have a class context; so, if we have
     59inc :: Num a => a -> a
     60inc = (+1)
     62what is the signature of the closure converted version?  We can't use
     64inc :: CConv (Num a => a -> a)
     66as associated types don't support that.  We probably want
     68inc :: Num a => CConv (a -> a)
     69-- OR
     70inc :: Num (CConv a) => CConv (a -> a)
     72As closure conversion happens on Core code, we need to be careful, as the context is not visible as such in the ''core view'' of types.