wondering about -ddump-parsed, rn

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

wondering about -ddump-parsed, rn

Isaac Dupree
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
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

RE: wondering about -ddump-parsed, rn

Simon Peyton Jones
-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: [hidden email] [mailto:[hidden email]] 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
| [hidden email]
| http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: wondering about -ddump-parsed, rn

Isaac Dupree
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
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: wondering about -ddump-parsed, rn

Christian Maeder-2
In reply to this post by Isaac Dupree
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
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: wondering about -ddump-parsed, rn

Isaac Dupree
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
_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: wondering about -ddump-parsed, rn

Stefan O'Rear
In reply to this post by Isaac Dupree
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

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: wondering about -ddump-parsed, rn

Isaac Dupree
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
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

RE: wondering about -ddump-parsed, rn

Simon Peyton Jones
| 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
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: wondering about -ddump-parsed, rn

Isaac Dupree
In reply to this post by Isaac Dupree
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
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

RE: wondering about -ddump-parsed, rn

Simon Peyton Jones
In reply to this post by Isaac Dupree
I'm not sure what you are suggesting here.  Can you be more explicit?

| -----Original Message-----
| From: Isaac Dupree [mailto:[hidden email]]
| 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
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: wondering about -ddump-parsed, rn

Isaac Dupree
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
_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users