Changes between Version 6 and Version 7 of Plugins


Ignore:
Timestamp:
Mar 21, 2008 9:54:44 PM (6 years ago)
Author:
guest
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • Plugins

    v6 v7  
    88 
    99'''Here be dragons! ''' This is just the result of my very preliminary thinking about how we might implement this in GHC. I am by no means an expert and so this section is certainly neither authoritative or correct! - Max Bolingbroke, March 08 
     10 
     11=== General Design Goals === 
     12 
     13I  
    1014 
    1115=== User Interface === 
     
    147151 4. Rename, type check as normal, though TcBinds.mkPragFun will need to be extended to splat binder-specific PLUGIN pragmas on those binders 
    148152 5. Desugarer will have to do something to make the pragma data structure syntax trees into an actual in-memory value. Essentially, we want to evaluate the expression in a context where it just has access to the constructors of the plugins imported data type library. We could reuse some of the GHCi apparatus to do this, see e.g. HscMain.compileExpr, HscMain.hscStmt and Linker.linkExpr. We then wrap this value up into an existential type that has a Dynamic instance and put it into the pragma on the Core (so the typechecker will have to make sure this part of the pragma has such an instance). 
    149  5. Give the plugin a chance to install core passes into the pipeline. For each one (assuming we use external core..): 
    150   1. Convert the input into external core. Note this loses information we try and construct in the core2core pipeline like demands and strictness, so this probably limits plugins to early or late in the pipeline where this doesn't matter, or else we will just have to reconstruct the info after every plugin pass.. 
    151   2. Feed the external core to the dynamically linked pass function. To ensure binary compatibility we will have to lift external-core out to a library that the stage2 compiler and the plugin both depend on.  
    152   3. The plugin will encounter CoreSyn Notes that include information about various binders: it can use Dynamic to try and cast the existentially typed value this contains to an appropriate type from the accompanying pragma data type library 
    153   3. Convert the returned core back into GHC core and give that to the next core2core stage. 
     153 5. Give the plugin a chance to install core passes into the pipeline. For each one: 
     154  1. Feed the core to the dynamically linked pass function. 
     155  2. The plugin will encounter CoreSyn Notes that include information about various binders OR will get a map of pragma information on a per-function basis. It can use Dynamic to try and cast the value this contains to an appropriate type from the accompanying pragma data type library 
     156  3. Give the returned core to the next core2core stage. 
    154157 6. Codegen etc as normal 
    155158 7. Add to the output file links to anything the plugin specified. Somehow record the extra library files to eventually link in, e.g. via a .hi file