Can we simplify Dynamic?

[Edward Kmett]

They aren't perfect, but if you find an SHA collision you have a
publishable result. ;)

-Edward

On Tue, Sep 29, 2015 at 11:11 AM, David Feuer <david.feuer at gmail.com> wrote:

> The potential for increased speed in limited applications was really just
> a happy side effect. I was mostly thinking about reducing the extent of the
> trusted code base and separating it more thoroughly from the rest. Another
> feature that you may or may not be able to reproduce with your current
> design is that it's possible to check types (slowly) with a higher degree
> of confidence than a system offering only testing up to fingerprint
> equivalence--hash functions aren't perfect.
> On Sep 29, 2015 9:47 AM, "Richard Eisenberg" <eir at cis.upenn.edu> wrote:
>
>>
>> On Sep 28, 2015, at 9:42 PM, David Feuer <david.feuer at gmail.com> wrote:
>>
>> I forgot to thank you and the rest for your tremendous work on this! I
>> know you said the page is a bit out of date, but I had an idea about
>> fingerprints you may want to consider if you haven't already. In
>> particular, the wiki page indicates that TTypeRep would have to be abstract
>> to prevent fingerprint forgeries, but I don't think that's necessarily
>> correct. I would think you could instead index the Fingerprint# type with
>> the type it identifies. You'd probably want to add a new magical
>> Fingerprinted class to produce fingerprints, and a magic function to use
>> them. The fingerprints could actually be used completely independently to
>> improve performance in contexts where the full power of TTypeRep isn't
>> required. Then the TTyperep nodes could hold Fingerprint#s, but themselves
>> be concrete. Presumably, Fingerprinted => Typeable. Maybe this idea is
>> crazy, but I figured I'd put it out there.
>>
>>
>> So, to paraphrase, this seems to propose two separate, similar mechanisms
>> for almost the same thing: Fingerprinted/Fingerprint# is just like
>> Typeable/TTypeRep, except that the former is not decomposable. In exchange,
>> working with the former might be faster.
>>
>> I agree that this might work, but I'm not sure the extra layer of
>> complexity pays its weight. Do you have an example where you think this
>> would matter in a large way? (that is, comparing type representations in a
>> tight loop)
>>
>> Also, we've made a solid restructuring of TypeRep since we last updated
>> that page. (When we're done writing the paper [next week?] we'll update the
>> page.) In its new form, TypeRep is decidedly abstract, but there is no more
>> TyCon type. Instead, some TypeReps are splittable and some aren't.
>>
>> Richard
>>
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20150929/ec2b1602/attachment-0001.html>