Quasi quoting

[Max Bolingbroke]

(Sorry if you see this twice, Simon - I didn't reply to the list)

2010/2/2 Simon Marlow <marlowsd at gmail.com>:
> 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