Wired-in type class
ggreif at gmail.com
Sun Aug 18 21:54:16 CEST 2013
On 8/18/13, Joachim Breitner <mail at joachim-breitner.de> wrote:
> 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
>> 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
>> And indeed they are slightly wrong: we are declaring NT as a data type
>> 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
In your case that would be an error.
More information about the ghc-devs