Changes between Version 14 and Version 15 of DataParallel/ClosureConversion/ClassLess


Ignore:
Timestamp:
Apr 23, 2007 10:59:31 AM (7 years ago)
Author:
chak
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • DataParallel/ClosureConversion/ClassLess

    v14 v15  
    7171 
    7272Apart from the standard rules, we need to handle the following special cases: 
    73  * We come across a value variable `v` where `idCC v == Nothing` whose type is `t`: we generate `convert t v` (see below). 
    74  * We come across a case expression where the scrutinised type `T` has `tyConCC T == Nothing`: we leave the case expression as is (i.e., unconverted), but make sure that the `idCC` field of all variables bound by patterns in the alternatives have their `idCC` field as `Nothing`.  (This implies that the previous case will kick in and convert the (unconverted) values obtained after decomposition.) 
    75  * Whenever we have an FC `cast` from or to a newtype `T`, where `tyConCC T == Nothing`, we need to add a `convert tau` or `trevnoc tau`, respectively.  We can spot these casts by inspecting the kind of every coercion used in a cast.  One side of the equality will have the newtype constructor. 
    76  * We come across a dfun: If its `idCC` field is `Nothing`, we keep the selection as is, but apply `convert t e` from it it, where `t` is the type of the selected method and `e` the selection expression.  If `idCC` is `Just d_CC`, and the dfun's class is converted, `d_CC` is fully converted.  If it's class is not converted, we also keep the selection unconverted, but have a bit less to do in `convert t e`.  '''TODO:''' This needs to be fully worked out. 
     73 * We come across a value variable `v` where `idCC v == NoCC` whose type is `t`: we generate `convert t v` (see below). 
     74 * We come across a case expression where the scrutinised type `T` has `tyConCC T == NoCC`: we leave the case expression as is (i.e., unconverted), but make sure that the `idCC` field of all variables bound by patterns in the alternatives have their `idCC` field as `NoCC`.  (This implies that the previous case will kick in and convert the (unconverted) values obtained after decomposition.) 
     75 * Whenever we have an FC `cast` from or to a newtype `T`, where `tyConCC T == NoCC`, we need to add a `convert tau` or `trevnoc tau`, respectively.  We can spot these casts by inspecting the kind of every coercion used in a cast.  One side of the equality will have the newtype constructor. 
     76 * We come across a dfun: If its `idCC` field is `NoCC`, we keep the selection as is, but apply `convert t e` from it, where `t` is the type of the selected method and `e` the selection expression.  If `idCC` is `ConvCC d_CC`, and the dfun's class is converted, `d_CC` is fully converted.  If it's class is not converted, we also keep the selection unconverted, but have a bit less to do in `convert t e`.  '''TODO:''' This needs to be fully worked out. 
    7777 
    7878=== Generating conversions === 
     
    8080Whenever 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: 
    8181{{{ 
    82 convert T          = id   , if tyConCC T == Nothing 
     82convert T          = id   , if tyConCC T == NoCC or AsIsCC 
    8383                   = to_T , otherwise 
    8484convert a          = id 
     
    8989where `trevnoc` is the same as `convert`, but using `from_T` instead of `to_T`. 
    9090 
    91 The 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. 
     91The 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 == NoCC` where we have to perform conversion. 
    9292 
    9393The 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.