Changes between Version 1 and Version 2 of Plugins/Annotations

Jun 23, 2008 11:53:03 PM (9 years ago)



  • Plugins/Annotations

    v1 v2  
     79== Possible Solution 3 ==
     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).
     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.
     92The syntax could be used in three ways. Like a traditional annotation:
     95data Stuff deriving Typeable
     97{-# ANN foo Stuff #-}
     98foo x = ...
     102The identifier does not necessarily have to be top level as this usage is immediately transformed as follows to ensure stability:
     106data Stuff deriving Typeable
     108foo = {-# ANN Stuff #-} \x -> ...
     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:
     115{-# ANN Stuff #-}
     117module Main where
     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.
     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
     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.
    78132== Other Considerations ==