For some time now I've been saying that Tim and I are working on the design of some enhancements to Template Haskell. It's taken longer than I'd hoped, and we aren't done yet, but you can find a draft at http://research.microsoft.com/~simonpj/tmp/notes.ps

Great stuff! I've recently done some TH work again, so let me add something to the wish-list: Another thing that I'm really missing with the current Template Haskell is a "decent" way to pass state between different meta-functions. Let me provide a few examples of the things I want to do: 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). In my case, the first meta function would declare an Objective-C class and the second one would register all classes with the Objective-C runtime. Manuel Chakravarty provided me with a nice workaround involving the use of (unsafePerformIO $ newIORef ...) global variables from the Q monad. But to make that scheme work transparently, I would still need things like reifyImportedModules :: [String] -- or Q [String] reifyCurrentModuleName :: String -- or Q String And of course, using unsafePerformIO is generally not a nice thing to do, so if somebody could think of a more general solution, that would be great. Another "ugly" idiom that I've been using a lot: I have a function declareClass :: String -> String -> Q [Dec]. $(declareClass "Bar" "Foo") declares Haskell data types for an Objective-C class "Bar", which is derrived from another Objecive-C class "Foo". But it also defines super_Bar = "Foo" because another meta-function will require that information. The identifier "super_Bar" will never be explicitly used by the user of my template library. So I have lots of identifiers where the associated meta-information is stored in separate variables whose name is somehow based on the original name. It works, but all that text manipulation feels more like shell scripts than Haskell... Cheers, Wolfgang

More things for the TH wish-list: I've been using TH to create language extensions. Unfortunately, the error messages are horrible because: 1) They contain a header generated by TH. This contains useful information like line numbers but it talks about TH instead of talking about my extension. I want to be able to format the error message header myself using information like filename and line number that TH provides to me. 2) They contain a body generated by TH. If the code my language extension generates is wrong, there's virtually no chance that any user (myself included) will figure it out from seeing the machine-generated Haskell code or being given the type error message. Better just to say there is a problem and leave it at that. I want to be able to construct the error message body myself using information like the expression being spliced before evaluation, after evaluation and the error message produced. A related issue is that I generate files corresponding to each TH module I compile. If ghc is producing a file called foo/bar.o, I'd like the name of the file to be foo/bar_stub.o. For this sort of application, I need access to the name of the input and output filenames. Finally, can you drop the 'tick' from variable names produced using gensym? If you'd used underscore, the variable name would be a legal C identifier too. (Ok, so this is a bit specialized but it's very easy to do.) -- Alastair Reid www.haskell-consulting.com

The other big thing on my wish list is to relax the requirement that templates go in a separate module from code that invokes the template. In Template Greencard, this is a major hassle because you have to put the code to handle C types (you typically define a new template for each C type) in a separate module from the code to handle C functions. -- Alastair Reid