I'll put my question at the very front of this message, and then give the context. My question: Are Template Haskell pattern quotations (i.e., [p| ... |]) not implemented in GHC because they are rather tricky to implement, or because there has not been demand for them? And now, the context. I am working on an embedded DSL/compiler in Haskell, and I want to make use of the recently-much-discussed quasiquoting mechanism to ease reading & writing various transformations. I read through the quasiquoting paper [1] again and played around with some simple examples. In the paper, Data.Generics is used so that the same parser can be used for quasiquoting both expressions and patterns. This requires adding constructors to the ASTs being quasiquoted for antiquotations to be possible. In my application, I don't anticipate using Data.Generics for parser reuse, for a few reasons: * I haven't read the SYB papers, and don't understand how Data.Generics or Data.Data work. * My ASTs in some cases involve GADTs with several phantom type parameters (is that the right terminology?), and DeriveDataTypeable does not work with them. * I don't want to add the extra constructors necessary to support antiquotation with the Data.Generics approach. So, I'm stuck writing separate ExpQ / PatQ parsers. (Actually, I can write the parser once, if it takes a dictionary of semantic actions as a parameter, in which case I only need to write the dictionary of ExpQ actions and the dictionary of PatQ actions.) When writing the ExpQ parser, I can use Template Haskell expression quotations, [| ... |]. When writing the PatQ parser, I have to resort to using the various pattern construction combinators, which is unfortunate! I'd like to be able to use pattern quotations instead. So, my question once again: How hard would it be to implement the pattern quotations from the Template Haskell paper in GHC? Sincerely, Brad References: [1] Geoffrey B. Mainland. Why It's Nice to be Quoted: Quasiquoting for Haskell. http://www.eecs.harvard.edu/~mainland/ghc-quasiquoting/mainland07quasiquotin...
The *splicing* of patterns is considered tricky, see:
http://hackage.haskell.org/trac/ghc/ticket/1476
Implementing pattern quotations might be less tricky, but I would
imagine to make them useful, you'd have to allow splicing things
*into* them, which requires implementing pattern splicing. That's my
non-expert take on the issue.
On Wed, Feb 3, 2010 at 7:32 PM, Brad Larsen
I'll put my question at the very front of this message, and then give the context.
My question: Are Template Haskell pattern quotations (i.e., [p| ... |]) not implemented in GHC because they are rather tricky to implement, or because there has not been demand for them?
And now, the context.
I am working on an embedded DSL/compiler in Haskell, and I want to make use of the recently-much-discussed quasiquoting mechanism to ease reading & writing various transformations.
I read through the quasiquoting paper [1] again and played around with some simple examples. In the paper, Data.Generics is used so that the same parser can be used for quasiquoting both expressions and patterns. This requires adding constructors to the ASTs being quasiquoted for antiquotations to be possible.
In my application, I don't anticipate using Data.Generics for parser reuse, for a few reasons: * I haven't read the SYB papers, and don't understand how Data.Generics or Data.Data work. * My ASTs in some cases involve GADTs with several phantom type parameters (is that the right terminology?), and DeriveDataTypeable does not work with them. * I don't want to add the extra constructors necessary to support antiquotation with the Data.Generics approach.
So, I'm stuck writing separate ExpQ / PatQ parsers. (Actually, I can write the parser once, if it takes a dictionary of semantic actions as a parameter, in which case I only need to write the dictionary of ExpQ actions and the dictionary of PatQ actions.) When writing the ExpQ parser, I can use Template Haskell expression quotations, [| ... |]. When writing the PatQ parser, I have to resort to using the various pattern construction combinators, which is unfortunate! I'd like to be able to use pattern quotations instead.
So, my question once again: How hard would it be to implement the pattern quotations from the Template Haskell paper in GHC?
Sincerely, Brad
References:
[1] Geoffrey B. Mainland. Why It's Nice to be Quoted: Quasiquoting for Haskell. http://www.eecs.harvard.edu/~mainland/ghc-quasiquoting/mainland07quasiquotin... _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
| My question: Are Template Haskell pattern quotations (i.e., [p| ... | |]) not implemented in GHC because they are rather tricky to | implement, or because there has not been demand for them? They are tricky! The trouble is that patterns *bind variables*. I don't know how to deal cleanly with this. For example f $p = ...g... g x = ...f... Are these mutually recursive? Not if $p expands to something that binds g! But we need to sort bindings into recursive groups before type checking. But splices must be typechecked before being run, so TH splices are run by the typechecker. 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... Simon
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.)
| If I understand Brad correctly, then what he needs is what he called | pattern quotation rather than splicing. ... | | 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? Oh, thank you for clarifying. I'd totally missed that. No, there's no problem at all with pattern quotes. (I've just done the work and it took 10 mins.) I'm already messing with the TH stuff in pursuit of the quasi-quote changes I advertised, so I'll commit it at the same time. That is TH pattern quotes will work but TH pattern splices will continue not to exist Thanks for sorting out my misunderstanding. Simon
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
participants (4)
-
Brad Larsen -
Robert Greayer -
Sebastian Fischer -
Simon Peyton-Jones