ORF and renamer - ghc-devs - Haskell.org

newer
Pattern synonym thoughts

ORF and renamer

older
"Excuse me, I think this i my...

Alan & Kim Zimmerman

23 Feb 2016 23 Feb '16

8:35 a.m.

I am working on updating HaRe for GHC 8.0.1, and have hit an issue with the following file --------------------------- module Field1 where --Rename field name 'pointx' to 'pointx1' data Point = Pt {pointx, pointy :: Float} absPoint :: Point -> Float absPoint p = sqrt (pointx p * pointx p + pointy p * pointy p) -------------------------- It seems that after the renamer, each of the three instances of `pointx` has a different `nameUnique` value. Is this because the final resolution is now done during type checking? If so it makes the RenamedSource much harder to work with. Alan

Reply

Sign in to reply online Use email software

Show replies by date

Adam Gundry

23 Feb 23 Feb

9:20 a.m.

Hi Alan, I certainly made a few changes to the renamer as part of the ORF work, but I wouldn't expect them to cause the behaviour you describe. Name resolution for ambiguous record selectors is deferred to the typechecker when the DuplicateRecordFields extension is enabled, but unambiguous selectors (as in your example) are resolved by the renamer. Moreover, I didn't touch anything to do with uniques. The record selector will be in scope once, with a single Name containing a single Unique. Unfortunately, I can't reproduce the behaviour you describe with: ghc-8.0.0.20160204 Field1.hs -ddump-rn-trace -dppr-debug Can you describe in more detail how to reproduce the problem? All the best, Adam On 23/02/16 13:35, Alan & Kim Zimmerman wrote:

I am working on updating HaRe for GHC 8.0.1, and have hit an issue with the following file

--------------------------- module Field1 where

--Rename field name 'pointx' to 'pointx1'

data Point = Pt {pointx, pointy :: Float}

absPoint :: Point -> Float absPoint p = sqrt (pointx p * pointx p + pointy p * pointy p) --------------------------

It seems that after the renamer, each of the three instances of `pointx` has a different `nameUnique` value.

Is this because the final resolution is now done during type checking? If so it makes the RenamedSource much harder to work with.

Alan

-- Adam Gundry, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

Reply

Sign in to reply online Use email software

Alan & Kim Zimmerman

1:29 p.m.

Hi Adam Thanks for the response. My initial mail was more of a sanity check to see if anything had in fact changed, as I saw that the ambiguous case is pushed to the type checker. I wanted to confirm the unambiguous case treatment. I will try to make a clearer description of what I see/am doing. Alan On Tue, Feb 23, 2016 at 4:20 PM, Adam Gundry wrote:

Hi Alan,

I certainly made a few changes to the renamer as part of the ORF work, but I wouldn't expect them to cause the behaviour you describe. Name resolution for ambiguous record selectors is deferred to the typechecker when the DuplicateRecordFields extension is enabled, but unambiguous selectors (as in your example) are resolved by the renamer. Moreover, I didn't touch anything to do with uniques. The record selector will be in scope once, with a single Name containing a single Unique.

Unfortunately, I can't reproduce the behaviour you describe with:

ghc-8.0.0.20160204 Field1.hs -ddump-rn-trace -dppr-debug

Can you describe in more detail how to reproduce the problem?

All the best,

Adam

On 23/02/16 13:35, Alan & Kim Zimmerman wrote:

...
I am working on updating HaRe for GHC 8.0.1, and have hit an issue with the following file

--------------------------- module Field1 where

--Rename field name 'pointx' to 'pointx1'

data Point = Pt {pointx, pointy :: Float}

absPoint :: Point -> Float absPoint p = sqrt (pointx p * pointx p + pointy p * pointy p) --------------------------

It seems that after the renamer, each of the three instances of `pointx` has a different `nameUnique` value.

Is this because the final resolution is now done during type checking? If so it makes the RenamedSource much harder to work with.

Alan

-- Adam Gundry, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Reply

Sign in to reply online Use email software

Alan & Kim Zimmerman

3:14 p.m.

Adam FYI, using https://github.com/alanz/ghc-dump-tree/tree/debug-name I can see that I have a bug elsewhere in my code. The output is http://lpaste.net/8427907315830620160, which includes the nameUnique for each Name in the RenamedSource. e.g. http://lpaste.net/8427907315830620160#line267 Regards Alan On Tue, Feb 23, 2016 at 8:29 PM, Alan & Kim Zimmerman wrote:

Hi Adam

Thanks for the response. My initial mail was more of a sanity check to see if anything had in fact changed, as I saw that the ambiguous case is pushed to the type checker. I wanted to confirm the unambiguous case treatment.

I will try to make a clearer description of what I see/am doing.

Alan

On Tue, Feb 23, 2016 at 4:20 PM, Adam Gundry wrote:

...
Hi Alan,

I certainly made a few changes to the renamer as part of the ORF work, but I wouldn't expect them to cause the behaviour you describe. Name resolution for ambiguous record selectors is deferred to the typechecker when the DuplicateRecordFields extension is enabled, but unambiguous selectors (as in your example) are resolved by the renamer. Moreover, I didn't touch anything to do with uniques. The record selector will be in scope once, with a single Name containing a single Unique.

Unfortunately, I can't reproduce the behaviour you describe with:

ghc-8.0.0.20160204 Field1.hs -ddump-rn-trace -dppr-debug

Can you describe in more detail how to reproduce the problem?

All the best,

Adam

On 23/02/16 13:35, Alan & Kim Zimmerman wrote:

...
I am working on updating HaRe for GHC 8.0.1, and have hit an issue with the following file

--------------------------- module Field1 where

--Rename field name 'pointx' to 'pointx1'

data Point = Pt {pointx, pointy :: Float}

absPoint :: Point -> Float absPoint p = sqrt (pointx p * pointx p + pointy p * pointy p) --------------------------

It seems that after the renamer, each of the three instances of `pointx` has a different `nameUnique` value.

Is this because the final resolution is now done during type checking? If so it makes the RenamedSource much harder to work with.

Alan

-- Adam Gundry, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Reply

Sign in to reply online Use email software

3374

Age (days ago)

3374

Last active (days ago)

Download

3 comments

2 participants

tags

participants (2)

Adam Gundry
Alan & Kim Zimmerman