Re: ORF and renamer
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 Zimmermanwrote: > 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 ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: ORF and renamer
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 Gundrywrote: > 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 ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: ORF and renamer
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
ORF and renamer
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 ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs