It is about functoriality in the sense that by providing a custom implementation for the unsafe method that uses unsafeCoerce you are asserting that your Functor really is one and doesn&#39;t do any GADT-like tricks on the functor argument and structurally complies with the laws.<div>
<br></div><div>It lets you lift core `cast`&#39;s out over the functorial argument, which isn&#39;t something I can do from outside of the class. If I tried to write something where the end user hands me an arbitrary Functor (or Profunctor) and I unsafeCoerce to cast, this would expose unsafeCoerce to the end user. </div>
<div><br></div><div>The implementation trick is to place these extra methods in the class but hidden in an explicitly Unsafe module and with default definitions that are correct but slow.</div><div><br></div><div>Then the provider of the functor-like class can explicitly import that module, and implement the methods, and mark his module Trustworthy. He hasn&#39;t exposed unsafeCoerce to the end user, they have to import an explicitly Unsafe module to get access to it, incurring the obligation themselves to provide something that is operationally id or a cast.</div>
<div><br></div><div>This enables you to have the efficient implementation but guarded by an explicitly Unsafe module so the end user has to import that to get the efficient functionality, but you can discharge your obligations locally.<div>
<br></div><div>Similarly you can discharge the obligation about the representation of the operation you are passing at the use site. This means that you can reason about these separately.</div><div><br></div><div>In theory a similar operation could be exposed for Functor in a similar Unsafe module permitting a more efficient implementation of vacuous to be implemented soundly in Data.Void preserving sharing and changing the asymptotics of the casting from f Void for data types where the end user is willing to incur the reasoning obligation, but frankly, I&#39;m not willing to fight that battle today. </div>
<div><br></div><div>-Edward<br><br><div class="gmail_quote">On Tue, Jan 8, 2013 at 8:16 PM, Ross Paterson <span dir="ltr">&lt;<a href="mailto:ross@soi.city.ac.uk" target="_blank">ross@soi.city.ac.uk</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Is the Unsafe module all about getting efficient conversions between<br>
types that have the same representations due to embedded newtypes?<br>
(If so, the issue is not about functoriality.)</blockquote></div></div></div>