Changes between Version 50 and Version 51 of DataParallel/ClosureConversion/ClassLess


Ignore:
Timestamp:
May 1, 2007 6:40:42 AM (7 years ago)
Author:
chak
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • DataParallel/ClosureConversion/ClassLess

    v50 v51  
    1111 
    1212For a type constructor `T` and its data constructors `C`, we have three alternatives: 
    13  1. The declaration introducing `T` and its constructors was compiled without conversion or we were unable to convert it, as it uses some language features that prevents conversion. 
    14  2. The converted variant `T_CC` coincides with `T` (e.g., because `T` neither directly nor indirectly involves arrows). 
    15  3. The converted variant `T_CC` differs from `T`. 
    16 In the last two cases, we also have a ''conversion constructor'' `isoT` whose type and function is described below. 
     13 1. The declaration introducing `T` and its constructors was compiled without conversion or we were unable to convert it, as it uses some language feature that prevents conversion. 
     14 2. A converted variant `T_CC` exists, but coincides with `T` (e.g., because `T` neither directly nor indirectly involves arrows). 
     15 3. A converted variant `T_CC` exists and differs from `T`. 
     16In the last two cases, we also have a ''conversion constructor'' `isoT` whose type and meaning is described below. 
    1717 
    1818An example of a feature that prevents conversion are unboxed values.  We cannot make a closure from a function that has an unboxed argument, as we can neither instantiate the parametric polymorphic closure type with unboxed types, nor can we put unboxed values into the existentially quantified environment of a closure. 
     
    118118=== Converting type declarations === 
    119119 
    120 ==== Preliminaries ==== 
    121  
    122 In the latter case, there is also a conversion constructor `isoT` between values inhabitating types formed from the original and converted constructor.   
    123  
    124120==== Conversion rules ==== 
    125121 
    126122If 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: 
    127  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. 
     123 1. If the declaration of `T` mentions another algebraic type constructor `S` for which there is '''no''' `S_CC`, then we cannot convert `T`. 
    128124 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.) 
    129125 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. 
     
    136132 * `CoercionTyCon` and `SuperKindTyCon`: They don't categorise values and are ignored during conversion. 
    137133 
     134==== Conversion constructor ==== 
     135 
     136Whenever, we set `T_CC`, we also need to generate a conversion constructor `isoT`.  If `T` has one or more arguments, the conversion is non-trivial, even for `T_CC == T`. 
     137 
    138138==== Converting data constructors ==== 
    139139