May 2003 - template-haskell

RE: [Template-haskell] reifyDecl: syntax and semantics
by Simon Peyton-Jones 07 May '03

07 May '03

| > -------------------- | > 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

1 0

Re: [Template-haskell] reifyDecl: syntax and semantics
by François-Régis Sinot 02 May '03

02 May '03

> Reification is difficult for lots of reasons. But here is a trick that > you might be able to use. > > Break your program into pieces, where you split the use of decls > you want to reify into two parts. > > -------------------- > d1 = [d| data T = ... |] > > splice d1 > > --------------------- > > Then you have a meta-variable "d1" with the reified form, and the > real data declaration because of the splice. > > Tim Sheard 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". Thanks. -fr-

1 0

reifyDecl: syntax and semantics
by François-Régis Sinot 02 May '03

02 May '03

Hi there "Reification is a language construct, not a function", as said in the paper. I would like to discuss this choice a bit, focusing on reifyDecl. First, I don't really see any justification for this restriction. As far as I can see, if we say, for instance: reifyDecl :: String -> Decl as long as the result is in the quotation monad, it should be okay, or shoudln't it ? Maybe there are some implementation considerations that I can't see behind that choice. I think at least constructs of the form reifyDecl $(con "Tree") should be allowed. At present, the parser rejects that. My second point is that the syntax is inconsistent with the intended semantics: for example, the documentation says that it should be possible to reify a function definition and a prototype. But if I ask reifyDecl length, what do I expect ? The def or the proto ? Same thing with reification of instance declarations. As a matter of fact, the present implementation does not seem to handle the cases of prototypes and instances, and I don't think it is an urgent matter. However, I think the syntax should not already forbid that. My last point, is that it is really impractical. I think it is a pity that such a powerful construct is in fact almost unusable because of poor syntactic restrictions. For example, I want to reify a datatype declaration and then generate a declaration, say for a function, depending on the structure of the datatype. I can do that, but I can't abstract from the original datatype, which I am not happy with. If you're not convinced yet, I can be a bit more specific about what I want to do. So, what do you think about that ? -fr-

2 3