RE: [Template-haskell] reifyDecl problem
| > But Section 8.1 of "Template Meta-programming for Haskell" says: | > | > "In a similar way, reifyDecl f, gives a data structure | > that represens the value declaration for f;..." | > | > and later "... useful to restrict the use of reifyDecl to type | > constructors, classes, or variables (e.g. functions) declared at the | > top level..." | > | > From that I made a conclusion that it is possible to reify function | > declarations (the most interesting ability of TH to me comparing with | > C++, for instance). And I still hope :) that it is possible and the | > error message above is just due to mere bug. | | This you definitely can't do and oh, how I wish you could. The closest | you can get is to define a function as reified code and then splice it. | Example: | | d_fun = [d| fun = <function body> |] You can certainly consider it a missing feature, if not exactly a bug (though the error message is horrible). I think you'll always be restricted to functions defined in the same module. For example import Prelude foo = $(do_it (reifyDecl map)) won't work, because 'map' isn't defined in this module. To make this work, I'd need to store the original source code for every function in each module's interface file, just in case someone later imported and reified it. But it seems a bit unpleasant for module boundaries to be significant in this way. I'm not sure what to do about this. I'd be interested to know whether the same-module restriction would defeat the purposes for the "oh, how I wish I could" applications. simon Simon
won't work, because 'map' isn't defined in this module. To make this work, I'd need to store the original source code for every function in each module's interface file, just in case someone later imported and reified it. But it seems a bit unpleasant for module boundaries to be significant in this way. I'm not sure what to do about this.
I'd be interested to know whether the same-module restriction would defeat the purposes for the "oh, how I wish I could" applications.
For the present application that I'm considering it for, not so much, although I can image it becoming a problem. The interface file problem is definitely something I can sympathise with but perhaps it's the only solution? What's the deal with MetaML where you can reify code at runtime? Does this mean you get the entire source code represented in the object code? Sean
participants (2)
-
Sean Seefried -
Simon Peyton-Jones