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


Ignore:
Timestamp:
Apr 23, 2007 4:12:49 AM (7 years ago)
Author:
chak
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • DataParallel/ClosureConversion/ClassLess

    v5 v6  
    6767 
    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. 
     69 
     70=== Issues, aka rl's complaints === 
     71 
     72==== Non-converted versus unchanged type declarations ==== 
     73 
     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 
     75{{{ 
     76data T = MkT Int 
     77data S = MkS (Int -> Int) 
     78}}} 
     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. 
     80 
     81==== FC Coercions ==== 
     82 
     83Closure conversion happens on Core, which means that constructors, such as `MkT` of 
     84{{{ 
     85-- unconverted 
     86newtype T a = MkT (a -> a) 
     87}}} 
     88in a definition 
     89{{{ 
     90-- converted 
     91foo :: (a -> a) -> T a 
     92foo f = MkT f 
     93}}} 
     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`. 
     95 
     96Generally, we need a story about treating coercions during conversion. 
     97 
     98==== Function type constructor ==== 
     99 
     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 
     101{{{ 
     102-- unconverted 
     103data T f = T (Int -> Int) (f Int Int) 
     104}}} 
     105used as `T (->)` in converted code.  What is `convert (T (->))`? 
     106 
     107==== Classes ==== 
     108 
     109It might be sufficient to never convert class declarations as a whole, but only their representation types.