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

Apr 20, 2007 2:00:18 PM (11 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.