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


Ignore:
Timestamp:
May 1, 2007 6:58:16 AM (8 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)