Changes between Version 4 and Version 5 of Plugins/Annotations


Ignore:
Timestamp:
Sep 10, 2008 12:41:35 PM (7 years ago)
Author:
batterseapower
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • Plugins/Annotations

    v4 v5  
    1414 * Plugin-specific data structures
    1515
     16== Implemented Solution ==
     17
     18== Possible Solution 4 ==
     19
     20This is the one I'm actually going to try and implement. Annotations will look like this:
     21
     22{{{
     23{-# ANN f 1 #-}
     24f = ...
     25
     26{-# ANN g Just ("foo", 1337) #-}
     27g = ...
     28}}}
     29
     30I.e. you annotate an actual identifier with an expression. We impose the further constraint that that expression has the form of an actual literal (including data constructors). In particular, general application is disallowed, so this is not kosher:
     31
     32{{{
     33{-# ANN f id 1 #-}
     34}}}
     35
     36You can introduce compile time compilation by using Template Haskell as usual:
     37
     38{{{
     39{-# ANN f $(id [| 1 |]) #-}
     40}}}
     41
     42We will need another notation to be able to refer to identifiers other than data constructor and function names, something like:
     43
     44{{{
     45{-# ANN type Foo Just 2 #-}
     46data Foo = Foo
     47}}}
     48
     49We also allow:
     50
     51{{{
     52{-# ANN module "I am an annotation" #-}
     53}}}
     54
     55In your annotation, you may refer to the names of things in the modules being compiled, but not their implementations:
     56{{{
     57data Foo = Foo ...
     58f = ...
     59g = ...
     60
     61-- OK:
     62{-# ANN f Just ('g, ''Foo) #-}
     63
     64-- Not OK:
     65{-# ANN f Just (f, Foo) #-}
     66}}}
     67
     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
     70Notice 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.
     71
     72= Out-of-date speculation below =
    1673
    1774== Other Considerations ==
     
    159216
    160217An interesting alternative might be to have a notion of an "annotation type" similar to the class name used by C# / Java, and let those types e.g. implicitly add NOINLINE semantics to what they are attached to. This should help stability of the names used in annotations at the cost of reducing optimization opportunities.
    161 
    162 
    163 == Possible Solution 4 ==
    164 
    165 This is the one I'm actually going to try and implement. Annotations will look like this:
    166 
    167 {{{
    168 {-# ANN f 1 #-}
    169 f = ...
    170 
    171 {-# ANN g Just ("foo", 1337) #-}
    172 g = ...
    173 }}}
    174 
    175 I.e. you annotate an actual identifier with an expression. We impose the further constraint that that expression has the form of an actual literal (including data constructors). In particular, general application is disallowed, so this is not kosher:
    176 
    177 {{{
    178 {-# ANN f id 1 #-}
    179 }}}
    180 
    181 You can introduce compile time compilation by using Template Haskell as usual:
    182 
    183 {{{
    184 {-# ANN f $(id [| 1 |]) #-}
    185 }}}
    186 
    187 We will need another notation to be able to refer to identifiers other than data constructor and function names, something like:
    188 
    189 {{{
    190 {-# ANN_TYPE Foo Just 2 #-}
    191 data Foo = Foo
    192 }}}
    193 
    194 You may refer to the names of things in the modules being compiled, but not their implementations:
    195 {{{
    196 data Foo = Foo ...
    197 f = ...
    198 g = ...
    199 
    200 -- OK:
    201 {-# ANN f Just ('g, ''Foo) #-}
    202 
    203 -- Not OK:
    204 {-# ANN f Just (f, Foo) #-}
    205 }}}
    206 
    207 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.
    208 
    209 Notice 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. 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.