Changes between Version 35 and Version 36 of DataParallel/ClosureConversion/ClassLess
 Timestamp:
 May 1, 2007 12:38:56 AM (7 years ago)
Legend:
 Unmodified
 Added
 Removed
 Modified

DataParallel/ClosureConversion/ClassLess
v35 v36 30 30 ==== Preliminaries ==== 31 31 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'' forvalues inhabitating types formed from the original and converted constructor. The type of these functions is as follows:32 The 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: 33 33 {{{ 34 34 isoTy (T::k1>..>kn>*) = forall _1 .. _n _1_CC .. _n_CC. … … 73 73 frArr (f :$ e) = frb . f e . toa 74 74 }}} 75 So, the function array constructor `(>)::*>*>*` has a `StatusCC` value of `ConvCC ((:>) , isoArr)`.75 So, the function array constructor `(>)::*>*>*` has a `StatusCC` value of `ConvCC ((:>)` with `isoArr` as the conversion constructor. 76 76 77 77 Closure application is defined as … … 85 85 If 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: 86 86 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)` generatinga 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.) 88 88 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`. 90 90 Moreover, we handle other forms of type constructors as follows: 91 91 * `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 conversionsfor 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. 93 93 * `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.) 94 94 * `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. … … 99 99 data Int = I# Int# 100 100 }}} 101 the `tyConCC` field of `Int` is set to `ConvCC (Int, isoInt)` with101 the `tyConCC` field of `Int` is set to `ConvCC Int` and we have 102 102 {{{ 103 103 isoInt :: Int :<>: Int … … 112 112 data Maybe a = Nothing  Just a 113 113 }}} 114 has a value of `ConvCC (Maybe, isoMaybe)`, where114 has a value of `ConvCC Maybe` and we have 115 115 {{{ 116 116 isoMaybe :: (a :<>: a_CC) > (Maybe a :<>: Maybe a_CC)