Changes between Version 47 and Version 48 of DataParallel/ClosureConversion/ClassLess


Ignore:
Timestamp:
May 1, 2007 5:55:36 AM (7 years ago)
Author:
chak
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • DataParallel/ClosureConversion/ClassLess

    v47 v48  
    66=== Conversion status === 
    77 
    8 To all `TyCon`s, `DataCon`s, and `Id`s, we add a value of type 
    9 {{{ 
    10 data StatusCC a  
    11   = NoCC      -- Declaration has not been converted 
    12   | ConvCC a  -- Here is the converted version 
    13 }}} 
    14 For example, `Id` gets a field of type `StatusCC Id`.  A declaration `thisDecl` can be in one of three categories: 
    15  * `NoCC`: We did not convert that declaration, either because it was declared in an unconverted module or because it uses some feature that prevents conversion. 
    16  * `ConvCC thisDecl`: Original and converted declaration coincide (e.g., type declarations not involving arrows directly or indirectly). 
    17  * `ConvCC convDecl`: The variant `convDecl` is the closure-converted form of `thisDecl`. 
     8All `TyCon`s, `DataCon`s, and `Id`s have a ''conversion status'' that determines how occurences of these entities are treated during conversion.  For an `Id` named `v`, we have two alternatives: 
     9 1. The binding of `v` was compiled without conversion and we have to use `v` itself in converted code, which requires the use of an in-place conversion function. 
     10 2. Otherwise, we have a converted variant `v_CC`, and we use `v_CC` instead of `v` in converted code. 
     11 
     12For 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`. 
    1816An 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. 
    19  
    20 '''TODO:''' We won't really store `StatusCC` in `TyCon`s, `DataCon`s, and `Id`s, but instead have three finite maps maintaining the same information. 
    2117 
    2218=== Conversion pairs ===