I have an alternative proposal: * haskell-src-exts (HSE) remains as it is now (modulo any changes that simply must be made to allow TH functionality, e.g. the Name type) * template-haskell is changed to depend on HSE for all the basic AST functionality, but defines the purely meta-level constructs. These include the Q monad and the Info data type for reification, and anything else that might be necessary to make meta-programming work. I'd be ok with that. GHC depends on containers in a similar way. And I agree that the separation of concerns might be useful..
I doubt there are any major technical obstacles here. Regarding the Name type, I can see two ways forward. Either we find that HSE's existing Annotations are enough to contain the extra information needed by TH. If we find that doesn't work, I have long considered parameterising the HSE AST on the type of Name. I'm sure we can find an alternative that suits all purposes. I think it's unlikely that annotations will work -- the whole Name type was quite hard enough to get right when I could express it directly, let alone encoding it in something else! Parameterising over Name might be fine though. Library-wise there is of course no problem having two packages with different names along-side each other. I guess the only real issue is how GHC decides which package to use. If GHC can deal with both packages separately, the rest should be easy enough. That said, if we had a migration tool then it might not even be needed. A migration tool would be HARD! Imagine taking a rats-nest of existing TH data constructors and re-expressing it as HSE constructors instead. Right. As much as I would love to jump on this, there are some reality checks involved. Since this is (mostly) orthogonal to my "day job" research, I'll need to consider my options and alternatives. But I definitely want to see this happen, along with (the rest of) my haskell-suite vision. I'll get back to you. Excellent! I'll await your thoughts. As you probably know I'm planning to make some significant changes to TH (in my blog post of a year or two ago), so it'd be quite a good plan to do it all at once. Simon
_______________________________________________ Cvs-ghc mailing list [email protected] http://www.haskell.org/mailman/listinfo/cvs-ghc
