wondering about -ddump-parsed, rn
Is ghc -ddump-parsed supposed to give parse-syntactically valid Haskell? It nearly does - the only way I've seen it not do so is infix type-signatures and some infix definitions. Answer: no, look at what it does to the operators with fixities. But, -ddump-rn seems better... file: (@@@) :: a a @@@ b = a + b : a + b ==================== Parser ==================== @@@ :: a @@@ a b = ((a + b) : a) + b ==================== Renamer ==================== @@@ :: a @@@ a b = (a + b) : (a + b) It would be interesting if that was a source-to-source transformation on Haskell: a way to delete all the comments and formatting of the original file. Putting parentheses around infix used as prefix would be nice. Of course... the renamer output depends on other modules, and must for the precise reason of imported fixity declarations! GHC isn't trying to do this so I really have no reason to ask it to :) P.S. this (-ddump-) is a nice way to see how some stages of GHC's processing are done, to get to know them a little, I think, after also looking through some code and Commentary Isaac
-ddump-parsed shows the program after parsing. All operator application are parsed *left-associative* with one precedence. Then the renamer re-associates them to respect precedence and associativity. So, no, -ddump-parsed will definitely not give syntactically valid Haskell. -ddump-rn probably will though. Simon | -----Original Message----- | From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell-users-bounces@haskell.org] On | Behalf Of Isaac Dupree | Sent: 09 August 2007 00:44 | To: GHC Users | Subject: wondering about -ddump-parsed, rn | | Is ghc -ddump-parsed supposed to give parse-syntactically valid Haskell? | It nearly does - the only way I've seen it not do so is infix | type-signatures and some infix definitions. Answer: no, look at what it | does to the operators with fixities. But, -ddump-rn seems better... | | file: | | (@@@) :: a | a @@@ b = a + b : a + b | | ==================== Parser ==================== | @@@ :: a | @@@ a b = ((a + b) : a) + b | | ==================== Renamer ==================== | @@@ :: a | @@@ a b = (a + b) : (a + b) | | | It would be interesting if that was a source-to-source transformation on | Haskell: a way to delete all the comments and formatting of the original | file. Putting parentheses around infix used as prefix would be nice. | Of course... the renamer output depends on other modules, and must for | the precise reason of imported fixity declarations! GHC isn't trying to | do this so I really have no reason to ask it to :) | | P.S. this (-ddump-) is a nice way to see how some stages of GHC's | processing are done, to get to know them a little, I think, after also | looking through some code and Commentary | | Isaac | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Simon Peyton-Jones wrote:
-ddump-parsed shows the program after parsing. All operator application are parsed *left-associative* with one precedence. Then the renamer re-associates them to respect precedence and associativity.
So, no, -ddump-parsed will definitely not give syntactically valid Haskell. -ddump-rn probably will though.
yes, in that case, would anyone mind if I find an easy way to change GHC to parenthesize those non-infix uses of operators? :) hmm... maybe _I_ would mind, since it makes "what GHC is doing" just a tiny bit less transparent to the user of -ddump-{rn,parsed}. :-) Isaac
On Thu, Aug 09, 2007 at 06:51:12AM -0300, Isaac Dupree wrote:
Simon Peyton-Jones wrote:
-ddump-parsed shows the program after parsing. All operator application are parsed *left-associative* with one precedence. Then the renamer re-associates them to respect precedence and associativity. So, no, -ddump-parsed will definitely not give syntactically valid Haskell. -ddump-rn probably will though.
yes, in that case, would anyone mind if I find an easy way to change GHC to parenthesize those non-infix uses of operators? :) hmm... maybe _I_ would mind, since it makes "what GHC is doing" just a tiny bit less transparent to the user of -ddump-{rn,parsed}. :-)
I fixed an identical bug in a copy of the code a few months ago. http://haskell.org/pipermail/libraries/2007-April/007317.html Unfortunately, I think TH was forked off from the in-compiler syntax tree too long ago for my fix to be useful... Stefan
Stefan O'Rear wrote:
On Thu, Aug 09, 2007 at 06:51:12AM -0300, Isaac Dupree wrote:
-ddump-parsed shows the program after parsing. All operator application are parsed *left-associative* with one precedence. Then the renamer re-associates them to respect precedence and associativity. So, no, -ddump-parsed will definitely not give syntactically valid Haskell. -ddump-rn probably will though. yes, in that case, would anyone mind if I find an easy way to change GHC to
Simon Peyton-Jones wrote: parenthesize those non-infix uses of operators? :) hmm... maybe _I_ would mind, since it makes "what GHC is doing" just a tiny bit less transparent to the user of -ddump-{rn,parsed}. :-)
I fixed an identical bug in a copy of the code a few months ago.
http://haskell.org/pipermail/libraries/2007-April/007317.html
Unfortunately, I think TH was forked off from the in-compiler syntax tree too long ago for my fix to be useful...
Also these -ddump- outputs qualified infix usages {{{ `P.++` }}} as an infix, where the backticks should not be there if it was Haskell. If you know what you did to fix TH, can you easily add all those fixes to this copy of the code? (muses hopefully) I see Simon PJ has removed the "wrong" -ddump-parsed parentheses :) Isaac
| I see Simon PJ has removed the "wrong" -ddump-parsed parentheses :) Ah yes, should have mentioned that. I think it's better now; turned out to be quick and easy. -dppr-debug shows the old form, for GHC debugging. Simon
I'm not sure what you are suggesting here. Can you be more explicit? | -----Original Message----- | From: Isaac Dupree [mailto:isaacdupree@charter.net] | Sent: 09 August 2007 10:51 | To: Simon Peyton-Jones | Cc: GHC Users | Subject: Re: wondering about -ddump-parsed, rn | | Simon Peyton-Jones wrote: | > -ddump-parsed shows the program after parsing. All operator application are parsed *left- | associative* with one precedence. Then the renamer re-associates them to respect precedence and | associativity. | > | > So, no, -ddump-parsed will definitely not give syntactically valid Haskell. -ddump-rn probably will | though. | | yes, in that case, would anyone mind if I find an easy way to change GHC | to parenthesize those non-infix uses of operators? :) hmm... maybe _I_ | would mind, since it makes "what GHC is doing" just a tiny bit less | transparent to the user of -ddump-{rn,parsed}. :-) | | Isaac
Simon Peyton-Jones wrote:
I'm not sure what you are suggesting here. Can you be more explicit?
e.g. (@@@) :: TypeSignature rather than @@@ :: TypeSignature , and if GHC transforms the source a @@@ b = ... into @@@ a b = ... (which it seems to do sometimes), then print (@@@) a b = ... instead. or if you meant
hmm... maybe _I_ | would mind, since it makes "what GHC is doing" just a tiny bit less | transparent to the user of -ddump-{rn,parsed}. :-)
, I changed my mind, since those parentheses mean a different thing from normal and that makes parentheses' meaning ambiguous (of course this was already changed in HEAD for the better) Isaac
Isaac Dupree wrote:
Is ghc -ddump-parsed supposed to give parse-syntactically valid Haskell? It nearly does - the only way I've seen it not do so is infix type-signatures and some infix definitions. Answer: no, look at what it does to the operators with fixities. But, -ddump-rn seems better...
file:
(@@@) :: a a @@@ b = a + b : a + b
==================== Parser ==================== @@@ :: a @@@ a b = ((a + b) : a) + b
Could -ddump-parsed not simply omit these (wrong) left-associative parentheses? What information would be lost? Cheers Christian
Christian Maeder wrote:
Isaac Dupree wrote:
@@@ a b = ((a + b) : a) + b
Could -ddump-parsed not simply omit these (wrong) left-associative parentheses? What information would be lost?
The information about how GHC's parser currently handles infixes. The intent of the -ddump-xxx flags (I think) is to give a readable representation of ghc's internal state, e.g. for debugging. However it very well might be that omitting those parentheses would yield a Haskell module equivalent to the original file, which would be a nice thing to be able to get somehow, anyway. Isaac
Also SPECIALIZE is turned into SPECIALIZE NOINLINE -- which has an effect on error messages too (which might be considered a bug). And instances look very weird.... source: instance Class.Eq Integer where CInteger a == CInteger b = a == b ghc-6.6.1 -ddump-parsed: instance {Class.Eq Integer} where [] { == CInteger a CInteger b = a == b } most recent HEAD -ddump-parsed: instance Class.Eq Integer where [] [] { == CInteger a CInteger b = a == b } Except for the two extra "[]" and the three necessary missing pairs of parentheses (or else using "==" in an infix position), this looks like valid Haskell And then my Num instance becomes (in HEAD) instance Class.Num Integer where [] [] { + CInteger a CInteger b = mkInteger (addInteger a b) * CInteger a CInteger b = mkInteger (multiplyInteger a b) negate (CInteger a) = mkInteger (negateInteger a) abs (CInteger a) = mkInteger (absInteger a) signum (CInteger a) = mkInteger (signumInteger a) fromInteger unboundedIntegral = mkInteger (uncheckedFromIntegral unboundedIntegral) } , which uses curly braces but not semicolons, so the layout wouldn't work in Haskell, for multiple functions defined in the instance, too. Isaac
participants (4)
-
Christian Maeder -
Isaac Dupree -
Simon Peyton-Jones -
Stefan O'Rear