Changes between Version 11 and Version 12 of Plugins


Ignore:
Timestamp:
Jul 31, 2008 10:20:44 PM (6 years ago)
Author:
guest
Comment:

Add annotation future work

Legend:

Unmodified
Added
Removed
Modified
  • Plugins

    v11 v12  
    55We would like to support dynamically-linked Core-to-Core plug-ins, so that people can add passes simply by writing a Core-to-Core function, and dynamically linking it to GHC. This would need to be supported by an extensible mechanism like attributes in mainstream OO languages, so that programmers can add declarative information to the source program that guides the transformation pass. Likewise the pass might want to construct information that is accessible later. This mechanism could obviously be used for optimisations, but also for program verifiers, and perhaps also for domain-specific code generation (the pass generates a GPU file, say, replacing the Core code with a foreign call to the GPU program).  
    66 
    7 == Implementation Speculation == 
     7== Future Work == 
     8 
     9Annotation related: 
     10 
     11 * Plugins cannot currently add further annotations during compilation that will be compiled into the result. I.e. any annotations they add are transient and disappear at the end of that particular run of the Core pipeline. 
     12  
     13 * We might want to add attribute metadata, so users can specify the multiplicity attributes should take, what sorts of things they can be attached to (value, type, module), and perhaps even what types they can be attached to (e.g. "only things of type a -> Bool for some a"), similar to C# ([http://msdn.microsoft.com/en-us/library/tw5zxet9(VS.80).aspx]) or Java. 
     14 
     15 * We might want to extend annotation syntax so you can attach multiple annotations in a single definition, like so: 
     16 
     17{{{ 
     18{-# ANN f, g, x Foo #-} 
     19f = ... 
     20g = ... 
     21x = ... 
     22}}} 
     23 
     24 * It might be nice to be able to write annotations in more places: 
     25 
     26   * Exports 
     27 
     28   * Function parameters 
     29 
     30   * Expressions (for plugins, similar to SCCs) 
     31 
     32   * Fields of data/newtype declarations 
     33 
     34   * Non-top-level identifiers (for plugins, tricky because such names are unstable) 
     35 
     36== (OUTDATED) Implementation Speculation == 
    837 
    938'''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