... | ... | @@ -82,9 +82,14 @@ deserialiseAnnEnv :: Typeable t => ([Word8] -> t) -> AnnEnv -> NameEnv t |
|
|
|
|
|
This function could be in main/Annotations.lhs.
|
|
|
|
|
|
|
|
|
## OLD Implementation Notes
|
|
|
|
|
|
****
|
|
|
|
|
|
|
|
|
**
|
|
|
**
|
|
|
|
|
|
|
|
|
|
|
|
In this old implementation, annotations look like this:
|
... | ... | @@ -150,10 +155,16 @@ Evaluation of the actual value of the annotation is done at the point they are a |
|
|
## Evolved Implementation
|
|
|
|
|
|
|
|
|
|
|
|
The Summer of Code implementation had some drawbacks:
|
|
|
|
|
|
|
|
|
- You don't detect non-terminating or otherwise "wrong" annotations at compile time
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
- It is difficult to specify an API that allows adding annotations to the program being compiled because that API needs both a value (that represents the annotation to plugins that may be later on in the pipeline) and a Core expression (that is inserted into the actual target program). What's more, you need to ensure that you are able to find a Typeable dictionary in the program being compiled that corresponds to the dictionary supplied by the user of the API.
|
|
|
|
|
|
- Modules must refer to all the packages that contain data structures used in their annotations. This may be a particular problem if you wish to annotate values with things from the GHC package.
|
... | ... | @@ -353,6 +364,10 @@ f :: ... |
|
|
|
|
|
- **(Only in SoC implementation)** 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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
- 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](http://msdn.microsoft.com/en-us/library/tw5zxet9(VS.80).aspx)) or Java.
|
|
|
|
|
|
- We might want to extend annotation syntax so you can attach multiple annotations in a single definition, like so:
|
... | ... | @@ -375,4 +390,4 @@ x = ... |
|
|
- **(Only in SoC implementation)** 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?
|
|
|
|
|
|
- Have retention policies, similar to Java?
|
|
|
- See also the Haskell Prime ticket: [ http://hackage.haskell.org/trac/haskell-prime/ticket/88](http://hackage.haskell.org/trac/haskell-prime/ticket/88) |
|
|
\ No newline at end of file |
|
|
- See also the Haskell Prime ticket: [ http://hackage.haskell.org/trac/haskell-prime/ticket/88](http://hackage.haskell.org/trac/haskell-prime/ticket/88) |