Changes between Version 5 and Version 6 of Plugins/Annotations


Ignore:
Timestamp:
Sep 10, 2008 12:46:11 PM (6 years ago)
Author:
batterseapower
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • Plugins/Annotations

    v5 v6  
    6666}}} 
    6767 
    68 (Side note: I believe it would make sense to allow annotations to use the implementations of values in the module being compiled,: after all, I believe 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. However, this has not been implemented.) 
    69  
    7068Notice 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 #-} 
     80f = ... 
     81g = ... 
     82x = ... 
     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 
    7196 
    7297= Out-of-date speculation below =