ORF and renamer
Alan & Kim Zimmerman
alan.zimm at gmail.com
Tue Feb 23 20:14:01 UTC 2016
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
<alan.zimm at gmail.com> 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 <adam at well-typed.com> 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 at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
More information about the ghc-devs
mailing list