<p dir="ltr">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.</p>
<div class="gmail_quote">On Sep 29, 2015 9:47 AM, "Richard Eisenberg" <<a href="mailto:eir@cis.upenn.edu">eir@cis.upenn.edu</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><br><div><div>On Sep 28, 2015, at 9:42 PM, David Feuer <<a href="mailto:david.feuer@gmail.com" target="_blank">david.feuer@gmail.com</a>> wrote:</div><br><blockquote type="cite"><p dir="ltr">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.</p><div><br></div></blockquote><br></div><div>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.</div><div><br></div><div>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)</div><div><br></div><div>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.</div><div><br></div><div>Richard</div></div></blockquote></div>