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

Apr 17, 2007 11:55:25 AM (8 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.