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

Timestamp:

04/30/07 23:40:42 (6 years ago)

Author:

chak

Comment:

--

DataParallel/ClosureConversion/ClassLess

@@ -11 +11 @@
 
 For a type constructor `T` and its data constructors `C`, we have three alternatives:
- 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.
- 2. The converted variant `T_CC` coincides with `T` (e.g., because `T` neither directly nor indirectly involves arrows).
- 3. The converted variant `T_CC` differs from `T`.
-In the last two cases, we also have a ''conversion constructor'' `isoT` whose type and function is described below.
+ 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.
+ 2. A converted variant `T_CC` exists, but coincides with `T` (e.g., because `T` neither directly nor indirectly involves arrows).
+ 3. A converted variant `T_CC` exists and differs from `T`.
+In the last two cases, we also have a ''conversion constructor'' `isoT` whose type and meaning is described below.
 
 An 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.
@@ -118 +118 @@
 === Converting type declarations ===
 
-==== Preliminaries ====
-
-In the latter case, there is also a conversion constructor `isoT` between values inhabitating types formed from the original and converted constructor.  
-
 ==== Conversion rules ====
 
 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:
- 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.
+ 1. If the declaration of `T` mentions another algebraic type constructor `S` for which there is '''no''' `S_CC`, then we cannot convert `T`.
  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.)
  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.
@@ -136 +132 @@
  * `CoercionTyCon` and `SuperKindTyCon`: They don't categorise values and are ignored during conversion.
 
+==== Conversion constructor ====
+
+Whenever, 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`.
+
 ==== Converting data constructors ====