ORF and renamer

Adam Gundry adam at well-typed.com
Tue Feb 23 14:20:06 UTC 2016

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- Field1.hs -ddump-rn-trace -dppr-debug

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

All the best,


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/

More information about the ghc-devs mailing list