Changes between Version 5 and Version 6 of DataParallel/ClosureConversion


Ignore:
Timestamp:
Apr 20, 2007 11:23:55 AM (8 years ago)
Author:
chak
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • DataParallel/ClosureConversion

    v5 v6  
    77
    88One option for implementing closure-conversion is to represent closure-converted types as an indexed type whose type index is the original type and to combine that indexed type in a type class with methods for converting between closure-converted and vanilla terms.  The details are under [wiki:DataParallel/ClosureConversion/Indexed indexed closure conversion].  There are two potential benefits for this approach: (1) we will probably have to do something similar for vectorisation anyway - see the [wiki:DataParallel/VectorisationSpec requirements of vectorisation] - and (2) it seems that we need less bookkeeping (e.g., the name of a closure converted data type is just the indexed type with the original data type as its index).  However, there are problems, too; in particular, as we currently don't have class contexts and polytypes as type indexes.
     9
     10=== Requirements of closure conversion ===
     11
     12==== The straight forward part ====
     13
     14The actual closure-conversion transformation on lambda terms, which we intend to perform on Core.
     15
     16==== Type declarations, classes, and instances ====
     17
     18''Type declarations.''
     19If the program contains a type declaration including an arrow type, we need a closure-converted version of that declaration (for use in the closure converted code); e.g., for
     20{{{
     21data T = MkT (Int -> Int)
     22}}}
     23we need
     24{{{
     25data T_CC = MkT_CC (Clo Int Int)
     26}}}
     27
     28''Classes.''
     29Moreover, if the closure-converted code uses a type class, we need a closure-converted type class.  It might appear that this is a non-issue on Core as classes have already been desugared to plain System F.  The trouble is that GHC does not use plain System F.  It extends it by a whole array of extra type features.  In particular, classes induce datatype declarations., and yhey almost always contain arrow types.  Hence, as we just discussed, they need to be transformed.  Matters are complicated by GHC not actually generating standalone datatypes declarations that are emitted into interface files, a class declaration siliently implies a data declaration - GHC calls this an ''iface declaration sub-binder''.  So, it appears best to create for every class as closure-converted class that - as all other class declarations - implies the closure-converted class representation datatype.
     30
     31==== Interface files ====
    932
    1033