(Sorry if you see this twice, Simon - I didn't reply to the list)
2010/2/2 Simon Marlow
Can you say precisely what it means to be "in an Exp context"?
In a Type context == a HsSpliceTy constructor in the existing GHC AST In an Exp context == a HsSpliceE constructor in the existing GHC AST In a Decl context == a SpliceD constructor in the existing GHC AST
This is a bit like Simon's type-directed name resolution idea, in that it's adding in a bit of ad-hoc overloading.
I don't think so - it's much easier to deal with than that. What sort of context the splice is in is purely syntactic, and we already have to work it out to implement the existing Template Haskell semantics. Our proposal does not complicate this at all.
The TH library would have to include a Haskell parser, which presents some engineering difficulties. TH can't be mutually recursive with GHC, so either the haskell-src-exts package has to be used or TH and GHC have to be merged.
This is a real issue. Using src-exts would be a good fix, especially because it would mean that the numerous tools and libraries that already use the src-exts data structure could be reused in your TH programs. Unfortunately it would either: a) Have to be a boot package, so that GHC can translate the spliced Exp or whatever into GHC's HsExpr b) Or we could let $() accept a HsExpr (exported by the GHC package). Users can then use src-exts as a non-boot package, along with another non-boot package similar to src-exts-meta (see Hackage) which translates src-exts types into the GHC ones for the splice. This would let us delete a lot of code from GHC (DsMeta, Covert..). It's a big change though, and I'm not sure how I feel about it. Cheers, Max