Quasi quoting

Max Bolingbroke batterseapower at hotmail.com
Wed Feb 3 12:13:03 EST 2010

On 3 February 2010 14:07, Sebastian Fischer <sebf at informatik.uni-kiel.de> wrote:
> With a class-based approach only one parser that creates values of the same
> type could be used in a program. It would not be possible to embed multiple
> languages that create TH.Exp to be spliced into a single program. With the
> current syntax, I can write [$myLang| ... |] and [$yourLang| ... |] in the
> same program and use different parsers although both create Exp values.

This is not the case, because you still have an instance "Quoted
String". Then you can write:

$(myLang [|..|])

Where myLang :: String -> Q Exp

The "Quoted Exp" instance you have in scope just determines what
default semantics for $([|...|]) you get! So you can use this
behaviour to change the default "language" from Haskell to whatever
you like, but importing a My.Lang.Module rather than
Language.Haskell.TH. This is a bit ugly though, and is more of an
unintentional feature than something I was designing for :-)

> This is more verbose than the proposed [myLang| ... |]. There seem to be
> different goals in the different proposals in this thread: 1. Simplify the
> syntax for quasi quoting (remove $, use different brackets), 2. make it more
> generally applicable (allow declarations and/or types to be quasi quoted),
> and 3. simplify and generalise its implementation (invent a single mechanism
> that unifies quasi quoting and TH splicing).

Yes - I should have made it clearer that our proposal had strayed
rather far from the original goal of reducing verbosity :-). Instead
it increases it in the QQ case - but in (IMHO) a good way.


More information about the Glasgow-haskell-users mailing list