Changes between Version 3 and Version 4 of DataParallel/ClosureConversion/ClassLess

Apr 20, 2007 2:00:18 PM (8 years ago)



  • DataParallel/ClosureConversion/ClassLess

    v3 v4  
    1212Incidentally, if during conversion we come across a type declaration that we don't know how to convert (as it uses fancy extensions), we just don't generate a conversion. 
     14Note that basic types, such as `Int` and friends, would have `tyConCC` set to `Nothing`, which is exactly what we want. 
    1416=== Class declarations === 
    5052=== Generating conversions === 
     54Whenever we had `convert t e` above, where `t` is an unconverted type and `e` a converted expression, we need to generate some conversion code.  This works roughly as follows in a type directed manner: 
     56convert T          = id   , if tyConCC T == Nothing 
     57                   = to_T , otherwise 
     58convert a          = id 
     59convert (t1 t2)    = convert t1 (convert t2) 
     60convert (t1 -> t2) = createClosure using (trevnoc t1)  
     61                     and (convert t2) on argument and result resp. 
     63where `trevnoc` is the same as `convert`, but using `from_T` instead of `to_T`. 
     65The idea is that conversions for parametrised types are parametrised over conversions of their parameter types.  Wherever we call a function using parametrised types, we will know these type parameters (and hence can use `convert`) to compute their conversions.  This fits well, because it is at occurences of `Id`s that have `idCC == Nothing` where we have to perform conversion. 
     67The 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.