Changes to Data.Typeable

[Gábor Lehel]

2011/7/14 Simon Marlow <marlowsd at gmail.com>:
> On 11/07/2011 15:25, Gábor Lehel wrote:
>>
>> 2011/7/11 Simon Marlow<marlowsd at gmail.com>:
>>>
>>> On 08/07/2011 17:36, Gábor Lehel wrote:
>>>>
>>>> 2011/7/7 Simon Marlow<marlowsd at gmail.com>:
>>>
>>> Yes, it's implementation-defined but non-varying.  I know some people
>>> have
>>> objected to these things being outside the IO monad before, but there is
>>> already plenty of precedent (System.Info.os, size of Int, isIEEE...).
>>>
>>> However, if we take it out of IO then it may limit the possible
>>> implementations.  Would the previous implementation, in which keys were
>>> assigned at runtime, still be valid?  It is still implementation-defined
>>> and
>>> non-varying, but only over a single run.
>>
>> That's the question. It's in IO now because, while the keys don't vary
>> over a single run, they do vary between them. Presumably the new
>> version should be 'pure' if and only if that's no longer true. The
>> upsides (of not being in IO) are obvious, but unfortunately I don't
>> know much at all about the potential downsides in terms of limiting
>> implementations.
>
> After talking with Simon Peyton Jones about this, I decided to deprecate
> typeRepKey and add Ord instances to TypeRep and TyCon.  Given that
> typeRepKey isn't returning an Int any more, it isn't adding anything over a
> direct Ord instance on TypeRep (we didn't do this before because the Ord
> instance would vary from run to run).
>
> So you can now make a Map with TypeRep as the key, however to do this
> efficiently you probably want to use a hash map, and make TypeRep Hashable
> (easy, just take a chunk of the fingerprint).

This sounds good. Thanks.

If I'm understanding-assuming correctly, the Ord instance for TypeRep
would be two 64-bit compares? That doesn't sound so horrible, even
without hashing.

>
> Cheers,
>        Simon
>
>
>>>
>>>> Albeit, the use case I had in mind was using Template Haskell to
>>>> construct a case statement over the literal Int values of the keys as
>>>> determined at compile time (hopefully compiling down to something like
>>>> a C switch statement), and I'm not sure if that's going to work if the
>>>> keys are no longer Ints. (That it wouldn't compile down to a switch
>>>> statement is one thing, but I'm not sure if the code would literally
>>>> be possible to write. Maybe it'd need a Lift instance?) Anyway, I
>>>> don't think it would hurt to take it out of IO if given the
>>>> opportunity, either way.
>>>
>>> The keys are 128-bit hashes, so it might still be possible to do
>>> something
>>> like this, but you would need access to the internal representations.
>>>  I'm
>>> planning to expose these via Data.Typeable.Internal (no guarantees about
>>> stability of this API, however).
>>
>> I was going to suggest that a Lift instance could be provided in
>> Language.Haskell.TH.Syntax, but I see now that there's quite a few
>> types which could have an instance and don't, so that probably belongs
>> in a separate proposal. Just having the internals available will
>> hopefully be 'good enough' for the use case I mentioned (which itself
>> is not that important, just a nice optimization).
>>
>>>
>>> Cheers,
>>>        Simon
>>>
>>>
>>
>>
>>
>
>



-- 
Work is punishment for failing to procrastinate effectively.