Wired-in type class

Gabor Greif ggreif at gmail.com
Sun Aug 18 21:54:16 CEST 2013

On 8/18/13, Joachim Breitner <mail at joachim-breitner.de> wrote:
> Hi,
> Am Sonntag, den 18.08.2013, 15:24 +0000 schrieb Simon Peyton-Jones:
>> * Make NT a wired-in Class.  We don't have any of these at the moment, but
>> there should be no difficulty in creating one, along the lines of the
>> wired-in TyCons in TysWiredIn.  Its data con should have the type
>> 	NT :: (a ~R# b) -> NT a b
>> * Also make ntCast a wired-in It (see example in MkId), with an unfolding
>> like
>> 	ntCast :: NT a b => a -> b
>> 	ntCast = /\ab. \d:NT a b.  \x:a.
>>                        case d of
>>                          NT (g : a ~R# b) -> x |> g
> thanks; the Core of ntCast looks very much like what I have at the
> moment (although I still use an intermediate datatype; but that can
> easily be changed later).
>> * In the base module, define NT as a data type, and ntCast as a function:
>> 	data NT a b where
>> 	   NT :: NT a a
>> 	ntCast :: NT a b -> a -> b
>> 	ntCast NT x = x
>> These definitions will never get imported, because the definitions are
>> wired-in.
>> And indeed they are slightly wrong: we are declaring NT as a data type
>> not
>> a class, and the type of NT will be
>> 	NT :: (a ~T# b) -> NT a b
>> But they may still be used if, for example, we say (map ntCast xs).
>> All that matters is that their execution behaviour is correct, which it
>> will be.
> Is there any reason to prefer such “slightly wrong” definitions which
> are overwritten with built-in stuff over simply putting the type
> constructors and functions into GHC.Prim?
>> * We are only going to allow GHC-derived instances of NT.
> Just to be sure: Preventing manual instances is currently not possible
> and such a feature would have to be added to GHC, right?

There is also user-supplied Typeable instances which are ignored (with
a warning?).

In your case that would be an error.



More information about the ghc-devs mailing list