Can we simplify Dynamic?

[David Feuer]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20150929/e45dc756/attachment.html>