Changes between Version 5 and Version 6 of DataParallel/ClosureConversion/ClassLess

Apr 23, 2007 4:12:49 AM (9 years ago)



  • DataParallel/ClosureConversion/ClassLess

    v5 v6  
    6868The only remaining problem is that a type parameter to a function may itself be a type parameter got from a calling function; so similar to classes, we need to pass conversion functions with every type parameter.  So, maybe we want to stick `fr` and `to` into a class after all and requires that all functions used in converted contexts have the appropriate contexts in their signatures.
     70=== Issues, aka rl's complaints ===
     72==== Non-converted versus unchanged type declarations ====
     74Many type declarations will not be changed by conversion, as they do not contain any arrows.  Hence, it is more economic to avoid generating a `_CC` version of these declarations.  I initially thought that we can ignore this for a moment, because it is only an optimisation.  However, consider
     76data T = MkT Int
     77data S = MkS (Int -> Int)
     79As we don't convert `Int`, we cannot convert `T` and `S`, which is a shame as their conversion is simple and (in the vectorisation case may affect performance dramatically).  As a matter of fact, if we identify declarations that need not be converted, then we would mark `Int` and `T` as such and can convert `S` easily.
     81==== FC Coercions ====
     83Closure conversion happens on Core, which means that constructors, such as `MkT` of
     85-- unconverted
     86newtype T a = MkT (a -> a)
     88in a definition
     90-- converted
     91foo :: (a -> a) -> T a
     92foo f = MkT f
     94have vanished, leaving only a coercion.  As `T` is not converted, we need to notice that we need to generate `MkT (fr f)`.  So, we need to spot the conversion representing `MkT`.
     96Generally, we need a story about treating coercions during conversion.
     98==== Function type constructor ====
     100It is clear how to treat types involving subtypes of the form `a -> b`.  It is less clear how to deal with partial applications of `(->)`.  Consider
     102-- unconverted
     103data T f = T (Int -> Int) (f Int Int)
     105used as `T (->)` in converted code.  What is `convert (T (->))`?
     107==== Classes ====
     109It might be sufficient to never convert class declarations as a whole, but only their representation types.