Exposing newtype coercions to Haskell

Richard Eisenberg eir at cis.upenn.edu
Tue Jul 23 12:43:06 CEST 2013


You're right, of course. I'm now thinking we really do need ~R# to make 
this work. That's annoying, but not technically difficult. I'll continue 
to think about this.

Richard

On 2013-07-23 10:00, Joachim Breitner wrote:
> Hi,
> 
> Am Dienstag, den 23.07.2013, 09:51 +0100 schrieb Richard Eisenberg:
>> A few responses:
>> 
>> - As Simon said, there is no great reason we don't have ~R# in Core.
>> It's just that we looked through GHC and, without newtype coercions,
>> there is no need for ~R#, so we opted not to include it. I'm still not
>> convinced we need it for newtype coercions, though. What if we have 
>> this
>> in Core?
>> 
>> > class NT a b = MkNT { castNT :: a -> b ; uncastNT :: b -> a }
>> > NTCo:Age :: Age ~R# Int         -- see [1]
>> > NTAgeInst :: NT Age Int
>> > NTAgeInst = MkNT { castNT = \(a :: Age). a |> NTCo:Age ; uncastNT = \(x
>> > :: Int). x |> sym NTCo:Age }
> 
> I thought about this class definition, and it is has the nice property
> that we can actually implement the methods by hand (without the
> zero-cost of course), which would be a good lint-like check that we do
> not generate illegal instances. The problem is that It it would not
> allow
> deriving instance NT a b => NT [a] [b]
> as there is no way to extract the coercion that was used in the
> implementation of NT a b. Hence the need to expose (to Core, not to tue
> user) the coercion in the class: The cast operations do not compose
> well.
> 
> Greetings,
> Joachim
> 
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs




More information about the ghc-devs mailing list