Re: ORF and renamer

[Alan & Kim Zimmerman]

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

Re: ORF and renamer

[Alan & Kim Zimmerman]

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

[Adam Gundry]

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

[Alan & Kim Zimmerman]

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

Re: [ANNOUNCE] GHC 8.0.1 release candidate 2

[Jens Petersen]

On 8 February 2016 at 03:13, Ben Gamari  wrote:
> http://downloads.haskell.org/~ghc/8.0.1-rc2/

Thank you for RC2.

I finally built ghc-8.0.0 for Fedora Rawhide (quick build):
https://copr.fedorainfracloud.org/coprs/petersen/ghc-8.0.1
(perf build is still ongoing).

One minor thing I noticed is that docdir seems have changed RC2 to be versioned.
ie the LICENSE files for the included libraries now get installed under
"/usr/share/doc/ghc-/html/libraries/*/" rather than
"/usr/share/doc/ghc/html/libraries/*/" before.
I managed to work around that by configuring with
--docdir=/usr/share/doc but it took me by surprise.

I should open a ticket I guess...

Jens
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs