On Thu, Feb 4, 2010 at 5:47 AM, Sebastian Fischer
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?
Sebastian
-- Underestimating the novelty of the future is a time-honored tradition. (D.G.)
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. Brad