Template Haskell pattern quotations
brad.larsen at gmail.com
Thu Feb 4 16:58:49 EST 2010
On Thu, Feb 4, 2010 at 5:47 AM, Sebastian Fischer
<sebf at informatik.uni-kiel.de> wrote:
> On Feb 4, 2010, at 8:58 AM, Simon Peyton-Jones wrote:
>> Unless I have a sudden revelation I don't expect to implement pattern
>> splices anytime soon.
>> On the other hand, pattern *quasiquotes* are fine; they are run by the
>> renamer before scope analysis is done. So you can certainly say
>> f [qq| ...blah.. |] = ...g...
> If I understand Brad correctly, then what he needs is what he called pattern
> quotation rather than splicing.
> He can write
> [e|True|] instead of conE (mkName "True")
> to implement the Exp parser of his quasi quoter but he cannot write
> [p|True|] instead of conP (mkName "True")
> to implement his Pat parser because GHC tells him that "Tempate Haskell
> pattern brackets are not supported yet".
> My impression is that the problems with pattern splicing are not affected by
> support for pattern brackets. We can define a quasi quoter qq to implement
> id :: a -> a
> id [$qq|x|] = x
> independently of whether we use pattern brackets in its definition or not.
> Or am I missing something?
> Is there a problem with adding support for pattern brackets on the
> right-hand side of function definitions in order to simplify the definition
> of quasi quoters?
> Underestimating the novelty of the future is a time-honored tradition.
Yes, I think you have nailed my problem, and described it better than
I did! It would be convenient to be able to use the pattern quotation
in the right hand side of a definition, when implementing a
quasiquoter without relying on the Data.Generics technique.
More information about the Glasgow-haskell-users