Changes between Version 4 and Version 5 of DataParallel/ClosureConversion


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

--

Legend:

Unmodified
Added
Removed
Modified
  • DataParallel/ClosureConversion

    v4 v5  
     1[[wiki:DataParallel Up]] 
    12== Closure conversion as part of vectorisation == 
    23 
    3 '''TODO:''' describe the treatment of higher-order functions and closure conversion here. The relevant paper is [http://www.cse.unsw.edu.au/~chak/papers/LCK06.html]. The approach is described in more detail in [http://opus.kobv.de/tuberlin/volltexte/2006/1286/]. 
     4'''TODO:''' Describe the treatment of higher-order functions and closure conversion here. The relevant paper is [http://www.cse.unsw.edu.au/~chak/papers/LCK06.html]. The approach is described in more detail in [http://opus.kobv.de/tuberlin/volltexte/2006/1286/]. 
    45 
    56=== Closure-converted types as indexed-types === 
    67 
    7 After some brainstorming, Roman and I (= Manuel) came to the conclusion that we can save ourselves a lot of bookkeeping if we can represent closure-converted types by indexed types (i.e., keeping track of which original types correspond to which converted types).  The details are under [wiki:DataParallel/ClosureConversion/Indexed indexed closure conversion]. 
     8One 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 
     11---- 
     12'''** OLD STUFF **''' 
     13 
    814 
    915=== From the Skype discussion, 16 Mar 07 ===