Wired-in type class

[Gabor Greif]

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.

Cheers,

    Gabor