[Template-haskell] reifyDecl: syntax and semantics

François-Régis Sinot francois-regis.sinot@laposte.net
02 May 2003 19:06:09 +0200


> I can't comment on the other parts, I would imagine it's an 
> implementation restriction that could be lifted, but with quite a bit of
> effort.  However, which documntation says reifyDecl reifies the type?  I
> don't remember reading that anywhere (though I may have just forgotten).
>  I've always thought of reifyDecl and it has always worked that way for
> me as providing the definition and only the definition.  There is a
> seperate construct (reifyType) for type information (I think last time I
> checked it wasn't implemented or maybe I'm thinking of something else).

Ok, so maybe it is a bit unclear what reifyDecl should do.
I was refering to the paper, where something like "for example datatype
declarations, etc." is said, and I assumed it should work the same
way for every case in Decl.
And actually, one may very well want to reify an instance declaration.
The case of prototypes is less clear, because there is an access to
(almost ?) the same information with reifyType. 
It may however be more convenient for some applications, I suppose.

> My solution for abstracting away which datatype to process, is simply to
> have the generation function be f :: Decl -> Decl, actually in my case
> it was genAlgebra :: String -> [Decl] -> Q [Dec].  Then, one would use
> it as:
> $(genAlgebra "Lang" [reifyDecl Type,reifyDecl Expr])
> not the prettiest solution, but not much worse than what it would be
> anyways.  However, I can think of other problems where this limitation
> may be an issue, your problem may be in that category.

Sure, there is a solution, thanks. However it is not really convenient.
In particular, suppose you want to write a library that performs that
kind of things (reify a declaration, and generate another one), then
your line above has to be written by the user !
This is clearly too much to ask. You'll tell me I just have to write a
preprocessor, sure, but again this is not really satisfactory.
If TH is intended to be widely distributed and used at middle-term, I
still think my "request" makes sense. Now, I understand this represents
some work, and that there are other priorities.

-fr-