On 8/18/13, Joachim Breitner <m...@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
_______________________________________________
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
