Dubious behavior in TH pretty printer
The Template Haskell pretty-printer handles infix/prefix distinction improperly, causing text generated using it to be unparsable. Example: stefan@stefans:~/daanpp$ ghci -fth ___ ___ _ / _ \ /\ /\/ __(_) / /_\// /_/ / / | | GHC Interactive, version 6.7.20070323, for Haskell 98. / /_\\/ __ / /___| | http://www.haskell.org/ghc/ \____/\/ /_/\____/|_| Type :? for help. Loading package base ... linking ... done. Prelude> :m + Language.Haskell.TH Prelude Language.Haskell.TH> runQ [| (+) 2 2 |] >>= print . ppr Loading package template-haskell ... linking ... done. GHC.Num.+ 2 2 I am trying to use the Template Haskell AST system for internal representation of terms in a derivation library that can output Haskell or feed directly into a splice. This "bug", unfixed, would force me to fork the TH pretty printer. What would people think of a patch changing the behavor to "Always produce parsable output"? (Yes, I'm offering to implement it.) Stefan
On Sat, Mar 31, 2007 at 01:00:06AM -0700, Stefan O'Rear wrote:
stefan@stefans:~/daanpp$ ghci -fth Prelude> :m + Language.Haskell.TH Prelude Language.Haskell.TH> runQ [| (+) 2 2 |] >>= print . ppr GHC.Num.+ 2 2
I am trying to use the Template Haskell AST system for internal representation of terms in a derivation library that can output Haskell or feed directly into a splice. This "bug", unfixed, would force me to fork the TH pretty printer. What would people think of a patch changing the behavor to "Always produce parsable output"? (Yes, I'm offering to implement it.)
Sounds great - the pretty-printer is intended to print in valid Haskell syntax. Thanks Ian
| I am trying to use the Template Haskell AST system for internal | representation of terms in a derivation library that can output | Haskell or feed directly into a splice. This "bug", unfixed, would | force me to fork the TH pretty printer. What would people think of a | patch changing the behavor to "Always produce parsable output"? (Yes, | I'm offering to implement it.) Good plan. You may find the function isSymOcc :: OccName -> Bool in OccName.lhs useful Send us a patch, by all means. Thanks for offering to help. Simon
On Mon, Apr 02, 2007 at 09:02:41AM +0100, Simon Peyton-Jones wrote:
| I am trying to use the Template Haskell AST system for internal | representation of terms in a derivation library that can output | Haskell or feed directly into a splice. This "bug", unfixed, would | force me to fork the TH pretty printer. What would people think of a | patch changing the behavor to "Always produce parsable output"? (Yes, | I'm offering to implement it.)
Good plan. You may find the function isSymOcc :: OccName -> Bool in OccName.lhs useful
Send us a patch, by all means.
I already sent a patch to the libraries list: http://haskell.org/pipermail/libraries/2007-April/007317.html This also fixes the printign of tilde-patterns. (That said, a new issue has been found - \ ((:) x xs) -> x pprs as \ (:) x xs -> x, incorrectly parend.) I didn't know about isSymOcc (indeed I never saw an OccName.lhs in template-haskell); I implemented it myself with dropWhile and isAlpha. Stefan
| I already sent a patch to the libraries list: | http://haskell.org/pipermail/libraries/2007-April/007317.html | | This also fixes the printign of tilde-patterns. Great, thanks. | I didn't know about isSymOcc (indeed I never saw an OccName.lhs in | template-haskell); I implemented it myself with dropWhile and isAlpha. Ah yes, of course. OccName is for GHC's syntax, not TH's. Still, you might want to look in compiler/basicTypes/OccName.lhs, if only to check that your impl and GHC's agree about what an operator is. Simon
participants (3)
-
Ian Lynagh -
Simon Peyton-Jones -
Stefan O'Rear