| > -------------------- | > d1 = [d| data T = ... |] | > | > splice d1 | | I definitely prefer your solution which just avoids reification, for | one simple reason: it works ! | Question is: is there any case where reification is indispensable or is | this trick general ? (and then why bother with reification ?) | | However, I'm still not very happy with this solution, because (again) | thinking of a library working on the reified declarations, then the | part above has to be written by the "user". I think the main reason for reifyDecl etc is so that you can write ordinary Haskell declarations, and subsequently (in another module, even) write (reifyDecl T) to get the decl for T. It is rather dependent on being able to *name* the thing whose decl you want; hence the difficulty with instance decls (which are anonymous) and defn vs type-signature for functions (where one name names two things). As to the "language-construct" question, the difficulty is this. If reifyDecl has type reifyDecl :: String -> Decl then the string would have to be looked up in some environment. Just which environment? The environment at which the 'reifyDecl' call is written? Or when the reifyDecl monadic computation is performed (perhaps much later). I guess the latter is what we want. That means the Q monad must support looking up strings in an environment, something I've been meaning to add for some time. For example, suppose we say in current TH foo (reifyDecl T) where T is some data type data T = MkT String Then 'foo' might walk over the constructors of T, and over the constructor's argument type(s), and might ultimately come across a type constructor "String" in that argument type. At that point, foo might want to reify the defn of String, so that it can see what manner of beast it might be. And bingo there's that monadic look up again. No one has actually asked for this yet, mind you, so it's kind of vaguely on my list. Simon