Changes between Version 1 and Version 2 of Plugins/Annotations


Ignore:
Timestamp:
Jun 23, 2008 11:53:03 PM (6 years ago)
Author:
guest
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • Plugins/Annotations

    v1 v2  
    7676}}} 
    7777 
     78 
     79== Possible Solution 3 == 
     80 
     81This solution has all annotations being desugared to Notes that live on the Core syntax tree. The reasons for this are as follows: 
     82 * It means annotations are basically stable at all points in the compile pipeline: you won't miss one if for example some inlining happens. This is nice and predictable for plugin authors. This is especially troublesome because some things are inlined very eagerly indeed (e.g. non-exported IDs that are referenced only once). 
     83 * It means that potentially something like SCCs could be implemented outside of GHC itself, which is very useful for plugins that perform analytics, which I suspect will be an important use case. 
     84 * Allows us to attach information to non top-level binders, which I think is essentially impossible if we require a name in the annotation (making non top-level binders stable is HARD). 
     85 
     86Disadavantages are that: 
     87 * It becomes harder to annotate types and data constructors: a similar effect can be achieved by supplying a module level annotation that references the appropriate object by quoting its name. 
     88 * Establishing relationships between objects in an annotation may become less principled if the annotation is forcibly attached to one of the objects. 
     89 * Lack of a simple Id -> Annotation lookup facility may make plugin development harder. 
     90 * Lack of a simple Id -> Annotation correspondence essentially rules out accessing these things externally in future. 
     91 
     92The syntax could be used in three ways. Like a traditional annotation: 
     93{{{ 
     94 
     95data Stuff deriving Typeable 
     96 
     97{-# ANN foo Stuff #-} 
     98foo x = ... 
     99 
     100}}} 
     101 
     102The identifier does not necessarily have to be top level as this usage is immediately transformed as follows to ensure stability: 
     103 
     104{{{ 
     105 
     106data Stuff deriving Typeable 
     107 
     108foo = {-# ANN Stuff #-} \x -> ... 
     109 
     110}}} 
     111 
     112And this usage may also be typed directly by the user in the expression language as with SCC annotations currently. This is the "true form" of most of the annotations we will use. The only other possibility is module level annotations: 
     113 
     114{{{ 
     115{-# ANN Stuff #-} 
     116 
     117module Main where 
     118 
     119... 
     120 
     121}}} 
     122 
     123All of these forms allow arbitrary expressions in "Stuff", which are renamed and typechecked almost as if they had been written inside a splice $() in Template Haskell but instead of having the thing inside the splice return Q Exp we require it returns a Typeable thing. This code will be executed during desugaring of the whole program to generate the actual value we will attach to the Core syntax tree in a note. 
     124 
     125This treatment has a few nice effects: 
     126 * References to names of non top-level things are disallowed by Template Haskell semantics 
     127 * We get quoting of variable, constructor, type and phase names for free and in a uniform manner 
     128 * We get free checking that the Stuff does not try to execute something defined in the module being compiled 
     129 
     130An 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. 
     131 
    78132== Other Considerations == 
    79133