| Also, TH tries to present the completely sugared language to the user; | otherwise it would probably work on something more like core. This really is a tension, and one I don't really know how to resolve. GHC does represent fully-sugared syntax, including even the placement of parens. I don't think TH need go to these lengths. TH generates code that we might read, but which is mainly intended to be compiled. It's *also* intended to be processed by other TH code, so the smaller the TH data type, the better. I conclude that TH should avoid gratuitous syntactic sugar. Anything that can be converted to a simpler equivalent form, should be. Hence I rather think that infix operators in TH are a mistake. What do they really buy us? Similarly an if-expression, and arithmetic sequence, and list expressions. On the other hand, a list comprehension is much more complicated to desugar, so probably deserves to be there. It'd be good to discuss this and perhaps agree some changes. Concerning data types, I think it'd be fine to present data types in a single, canonical representation as a data type, probably something like the GADT style. That'd be a breaking change, mind you. Because there are design choices here, I'm dubious about getting any of this into 6.6. Time is very short, and we don't want to make a change that we re-change later. Simon