Changes between Version 35 and Version 36 of DataParallel/ClosureConversion/ClassLess


Ignore:
Timestamp:
May 1, 2007 12:38:56 AM (7 years ago)
Author:
chak
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • DataParallel/ClosureConversion/ClassLess

    v35 v36  
    3030==== Preliminaries ==== 
    3131 
    32 The alternatives of `TyCon.TyCon` get a new field `tyConCC :: StatusCC (TyCon, Id)`.  This field is `NoCC` for data constructors for which we have no conversion and `ConvCC (T_CC, iso_T)` if we have a conversion, where the converted declaration `T_CC` may coincide with `T`.  The value `iso_T` is a ''conversion constructor'' for values inhabitating types formed from the original and converted constructor.  The type of these functions is as follows: 
     32The alternatives of `TyCon.TyCon` get a new field `tyConCC :: StatusCC TyCon`.  This field is `NoCC` for data constructors for which we have no conversion and `ConvCC T_CC` if we have a conversion, where the converted declaration `T_CC` may coincide with `T`.  In the latter case, there is also ''conversion constructor'' `isoT` between values inhabitating types formed from the original and converted constructor.  The type of these functions is as follows: 
    3333{{{ 
    3434isoTy (T::k1->..->kn->*) = forall _1 .. _n _1_CC .. _n_CC. 
     
    7373    frArr (f :$ e) = frb . f e . toa 
    7474}}} 
    75 So, the function array constructor `(->)::*->*->*` has a `StatusCC` value of `ConvCC ((:->), isoArr)`. 
     75So, the function array constructor `(->)::*->*->*` has a `StatusCC` value of `ConvCC ((:->)` with `isoArr` as the conversion constructor. 
    7676 
    7777Closure application is defined as 
     
    8585If a type declaration for constructor `T` occurs in a converted module, we need to decide whether to convert the declaration of `T`.  We decide this as follows: 
    8686 1. If the declaration of `T` mentions another algebraic type constructor `S` with `tyConCC S == NoCC`, we cannot convert `T` and set its `tyConCC` field to `NoCC` as well. 
    87  2. If '''all''' algebraic type constructors `S` that are mentioned in `T`'s definiton have `tyConCC S == ConvCC S`, we do not convert `T` and set its `tyConCC` field to `ConvCC (T, isoT)` generating a suitable conversion constructor `isoT`.  (NB: The condition implies that `T` does not mention any function arrows.) 
     87 2. If '''all''' algebraic type constructors `S` that are mentioned in `T`'s definiton have `tyConCC S == ConvCC S`, we do not convert `T`, but set its `tyConCC` field to `ConvCC T` and generate a suitable conversion constructor `isoT`.  (NB: The condition implies that `T` does not mention any function arrows.) 
    8888 3. If the declaration of `T` uses any features that we cannot (or for the moment, don't want to) convert, we set its `tyConCC` field to `NoCC` - except if Case 2 applies. 
    89  4. Otherwise, we generate a converted type declaration `T_CC` together a conversion constructor  `isoT`, and set `tyConCC` to `ConvCC (T_CC, isoT)`.  Conversion proceeds by converting all data constructors (including their workers and wrappers), and in particular, we need to convert all types in the constructor signatures by replacing all type constructors that have conversions by their converted variant.  Data constructors get a new field `dcCC :: StatusCC DataCon`. 
     89 4. Otherwise, we generate a converted type declaration `T_CC` together a conversion constructor  `isoT`, and set `tyConCC` to `ConvCC T_CC`.  Conversion proceeds by converting all data constructors (including their workers and wrappers), and in particular, we need to convert all types in the constructor signatures by replacing all type constructors that have conversions by their converted variant.  Data constructors get a new field `dcCC :: StatusCC DataCon`. 
    9090Moreover, we handle other forms of type constructors as follows: 
    9191 * `FunTyCon`: It's `StatusCC` value was defined above.  We handle any occurence of the function type constructor like that of an algabraic type constructor with the `StatusCC` value given above, but we may not want to explcitly store that value in a field of `FunTyCon`, as `(:->)` would then probably need to go into `TyWiredIn` in. 
    92  * `TupleTyCon`: The `StatusCC` value of a tuple constructor `T` is `ConvCC (T, isoT)`, where `isoT` is a suitable conversion function; i.e., we don't need converted tuple type constructors, but we need to define conversions for all supported tuple types somewhere.  Unfortunately, there are many tuple types, and hence, many conversion functions.  An alternative might be to special case tuples during conversion generation and just inline the needed case construct. 
     92 * `TupleTyCon`: The `StatusCC` value of a tuple constructor `T` is `ConvCC T`; i.e., we don't need converted tuple type constructors.  However, we need a suitable conversion functions `isoT` for all supported tuple types somewhere.  Unfortunately, there are many tuple types, and hence, many conversion functions.  An alternative might be to special case tuples during conversion generation and just inline the needed case construct. 
    9393 * `SynTyCon`: Closure conversion operates on `coreView`; hence, we will see no synonyms.  (Well, we may see synonym families, but will treat them as not convertible for the moment.) 
    9494 * `PrimTyCon`: We essentially ignore primitive types during conversion.  We assume their converted and unconverted form are identical, which implies that they never inhibit conversion and that they need no conversion constructors. 
     
    9999data Int = I# Int# 
    100100}}} 
    101 the `tyConCC` field of `Int` is set to `ConvCC (Int, isoInt)` with 
     101the `tyConCC` field of `Int` is set to `ConvCC Int` and we have 
    102102{{{ 
    103103isoInt :: Int :<->: Int 
     
    112112data Maybe a = Nothing | Just a 
    113113}}} 
    114 has a value of `ConvCC (Maybe, isoMaybe)`, where 
     114has a value of `ConvCC Maybe` and we have 
    115115{{{ 
    116116isoMaybe :: (a :<->: a_CC) -> (Maybe a :<->: Maybe a_CC)