<p dir="ltr">I meant reflection in the sense of the reflection package. Sorry for the confusion.</p>
<div class="gmail_quote">On Jun 19, 2016 4:28 AM, "Ben Gamari" <<a href="mailto:ben@smart-cactus.org">ben@smart-cactus.org</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">"Edward Z. Yang" <<a href="mailto:ezyang@mit.edu">ezyang@mit.edu</a>> writes:<br>
<br>
snip<br>
<br>
>> Dictionaries are harder to come by,<br>
>> but reflection might be an option.<br>
><br>
> If I understand correctly, even if you have a Typeable dictionary you<br>
> don't necessarily have a way of constructing the other dictionaries<br>
> that are available at that type.  Maybe that is something worth fixing.<br>
><br>
Right; a Typeable dictionary gives you nothing more than the identity of<br>
the type. You cannot get any further dictionaries from it. Honestly<br>
fixing this seems quite non-trivial (essentially requiring that you<br>
construct a symbol name for the desired dictionary and do a symbol table<br>
lookup to find it, hoping that the linker didn't decide to drop it due<br>
to being unused).<br>
<br>
Moreover, it seems possible that providing this ability may have<br>
consequences on parametricity. Reflection already comes dangerously<br>
close to compromising this property; we are saved only by the fact that<br>
a Typeable constraint is needed to request a representation. I'd imagine<br>
that allowing the user to produce arbitrary dictionaries from a<br>
representation may pose similar issues.<br>
<br>
Cheers,<br>
<br>
- Ben<br>
</blockquote></div>