RE: wondering about -ddump-parsed, rn
I'm not sure what you are suggesting here. Can you be more explicit?
| -Original Message-
| From: Isaac Dupree [mailto:[EMAIL PROTECTED]
| 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
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: wondering about -ddump-parsed, rn
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
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: wondering about -ddump-parsed, rn
| 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 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: wondering about -ddump-parsed, rn
Stefan O'Rear wrote:
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...
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
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: wondering about -ddump-parsed, rn
-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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
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
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: wondering about -ddump-parsed, rn
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 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: wondering about -ddump-parsed, rn
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
signature.asc
Description: Digital signature
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
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
