On Thu, Feb 4, 2010 at 5:47 AM, Sebastian Fischer <s...@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? > > 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 _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users