Changes between Version 52 and Version 53 of DataParallel/ClosureConversion/ClassLess


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

--

Legend:

Unmodified
Added
Removed
Modified
  • DataParallel/ClosureConversion/ClassLess

    v52 v53  
    134134==== Conversion constructor ==== 
    135135 
    136 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`. 
     136Whenever we have a converted type constructor `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`. 
    137137 
    138138==== Converting data constructors ==== 
    139139 
    140 We convert data constructors by converting their argument types and their representation `DataCon` gets a new filed `dcCC :: StatusCC DataCon`.  In particular, the signature of the worker is converted.  However, in contrast to other functions, we only convert the argument and result types; the arrows tying them together are left intact.  For example, if the original wrapper has the type signature 
     140We convert a data constructor `C :: t1 -> ... -> tn` by generating a converted constructor `C_CC :: t1^ -> .. -> tn^`.  This includes the generation of a corresponding new worker `Id`.  For example, if the original worker has the type signature 
    141141{{{ 
    142142MkT :: (Int -> Int) -> Int 
    143143}}} 
    144 the converted wrapper is  
     144the converted worker is  
    145145{{{ 
    146146MkT_CC :: (Int :-> Int) -> Int 
    147147}}} 
    148 As a consequence, whenever we convert a ''partial'' wrapper application in an expression, we need to introduce a closure on the spot. 
     148As a consequence, whenever we convert a ''partial'' wrapper application in an expression, we need to introduce a closure on the spot.  (Simon pointed out that this is a rare case anyway.) 
    149149 
    150150We do not specially handle wrappers of data constructors.  They are converted just like any other toplevel function. 
     
    156156data Int = I# Int# 
    157157}}} 
    158 the `tyConCC` field of `Int` is set to `ConvCC Int` and we have 
     158we get `Int_CC = Int` and we have 
    159159{{{ 
    160160isoInt :: Int :<->: Int 
     
    165165}}} 
    166166 
    167 As another example, the `tyConCC` field of 
     167As another example, 
    168168{{{ 
    169169data Maybe a = Nothing | Just a 
    170170}}} 
    171 has a value of `ConvCC Maybe` and we have 
     171implies `Maybe_CC = Maybe` and 
    172172{{{ 
    173173isoMaybe :: (a :<->: a_CC) -> (Maybe a :<->: Maybe a_CC) 
     
    183183=== Converting classes and instances === 
    184184 
    185 We don't alter class and instance declarations in any way.  However, the dictionary type constructors and dfuns are processed in the same way as other data types and value bindings, respectively; i.e., they get a `StatusCC` field and we generate converted versions and conversion constructors as usual. 
     185We don't alter class and instance declarations in any way.  However, the dictionary type constructors and dfuns are converted in the same way as other data types and value bindings, respectively. 
    186186 
    187187As an example, assume `Num Int` were defined as 
     
    211211    negate_CC :: a :-> a 
    212212  } 
    213 dNumInt_CC :: Num_CC Int  -- Int \equiv Int_CC 
     213dNumInt_CC :: Num_CC Int   -- as Int_CC = Int 
    214214dNumInt_CC = Num_CC  
    215215               (to isoIntToIntToInt primAddInt)