Changes between Version 6 and Version 7 of Plugins/Annotations


Ignore:
Timestamp:
Oct 10, 2008 10:23:48 AM (6 years ago)
Author:
batterseapower
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • Plugins/Annotations

    v6 v7  
    1414 * Plugin-specific data structures 
    1515 
    16 == Implemented Solution == 
     16As the annotations system is orthogonal to plugins, further development of this page will take place at [[Plugins]]. 
     17 
     18= Out of date speculation below = 
     19 
     20== Previously Implemented Solution == 
    1721 
    1822== Possible Solution 4 == 
     
    6771 
    6872Notice that this notation does not allow annotating non-top-level names or expressions, and due to its use of an Id -> Annotation mapping may not survive inlining (this only matters to plugins, not users of annotations on exported stuff). These are annoying limitations but it does fit with our view that the annotations should be exportable and accessible by an Id -> Annotation mapping by other modules. 
    69  
    70 == Future Work == 
    71  
    72  * 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. 
    73   
    74  * 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. 
    75  
    76  * We might want to extend annotation syntax so you can attach multiple annotations in a single definition, like so: 
    77  
    78 {{{ 
    79 {-# ANN f, g, x Foo #-} 
    80 f = ... 
    81 g = ... 
    82 x = ... 
    83 }}} 
    84  
    85  * It might be nice to be able to write annotations in more places: 
    86   * Exports 
    87   * Function parameters 
    88   * Expressions (for plugins, similar to SCCs) 
    89   * Fields of data/newtype declarations 
    90   * Non-top-level identifiers (for plugins: tricky because such names are unstable) 
    91  
    92  * I believe it would make sense to allow annotations to use the implementations of values in the module being compiled,: after all, I they can use the implementations of values in imported modules. This would filling out the relevant field with an error during compilation (for the benefit of plugins) and linking the annotation fields up to the required values after compilation. Is this a good idea? 
    93  
    94  * Have retention policies, similar to Java? 
    95  * See also the Haskell Prime ticket: http://hackage.haskell.org/trac/haskell-prime/ticket/88 
    96  
    97 = Out-of-date speculation below = 
    9873 
    9974== Other Considerations ==