[Template-haskell] RE: Template Haskell...
Alastair Reid
alastair at reid-consulting-uk.ltd.uk
Thu Oct 30 10:23:39 EST 2003
On Thursday 30 October 2003 9:32 am, Simon Peyton-Jones wrote:
> | I have one meta-function that generates declarations; and I have
> | another meta function that needs to know what definitions generated by
> | the first meta function there are (accross module boundaries).
>
> I'm not sure what you're asking for here. Some kind of monadic function
> that stores persistent state, that persists across multiple
> compilations? Presumably held in the file system? Some kind of
> database?
A simple approach would be to allow us to write things into the .hi file.
For example, the function:
write :: String -> Q ()
would write some data into the .hi file. The concrete representation in
the .hi file could be something as simple as:
<START_TH>your data here<END_TH>
GHC would be responsible for using an escape mechanism on the offchance that
the string happened to contain the string "<END_TH>".
Since several things could be written into the .hi file, read should return
all of them:
read :: Q [String]
This would return all strings in all .hi files for all directly imported
modules.
In some cases, we want the strings for all _indirectly_ imported modules too.
(That is, to give behaviour like that seem for typeclass instances.)
This would require that these strings get propagated from one module to
another. Since this isn't always wanted, maybe there should be two kinds of
'write': one to write strings which are propagated and one to write strings
which are not.
Also, for convenience, we might want a slightly more complex interface which
lets users specify a 'tag' (which would often be the name of the splice
library being used - e.g., "TemplateGreencard") and in which GHC
automatically adds the module name too:
write :: Tag -> String -> Q ()
read :: Q [(ModuleId,Tag,String)]
> Alastair wants per-module persistence. I'm sceptical about that because
> TH makes absolutely no guarantees about which order things will be
> evaluated in. So how would you know which effect occurs first?
I guess all the TH code I write uses top-level splices so I hadn't thought
about this issue.
Two solutions suggest themselves:
1) Restrict writes to top-level splices.
2) Allow writes anywhere and warn users about potential non-determinism.
--
Alastair Reid www.haskell-consulting.com
More information about the template-haskell
mailing list