Whoops, sending this to the whole list. Sorry for the duplication, Simon.<br clear="all"><br><div>-- Dan Burton<br>
<br><br><div class="gmail_quote">---------- Forwarded message ----------<br>From: <b class="gmail_sendername">Dan Burton</b> <span dir="ltr">&lt;<a href="mailto:danburton.email@gmail.com">danburton.email@gmail.com</a>&gt;</span><br>

Date: Fri, Oct 5, 2012 at 11:57 AM<br>Subject: Re: Changes to Typeable<br>To: Simon Peyton-Jones &lt;<a href="mailto:simonpj@microsoft.com">simonpj@microsoft.com</a>&gt;<br><br><br>I was alluding to what Brent Yorgey and others already said. If I annotate a function with the type signature <span style="color:rgb(34,34,34);font-size:13px;font-family:&#39;courier new&#39;,monospace">(</span><span style="color:rgb(34,34,34);font-size:13px"><font face="courier new, monospace">a -&gt; Int)</font><font face="arial, helvetica, sans-serif"> then that function should *not* have access to typeable operations on its input (because then we would lose our precious free theorems).</font></span><div>


<span style="color:rgb(34,34,34);font-size:13px"><font face="arial, helvetica, sans-serif"><br></font></span></div><div><span style="color:rgb(34,34,34);font-size:13px"><font face="arial, helvetica, sans-serif">If a function is not annotated, but uses typeable operations, then type inference should indicate the corresponding Typeable constraints in the inferred type. To steal Brent&#39;s example:</font></span></div>


<div><font color="#222222" face="arial, helvetica, sans-serif"><br></font></div><div><div class="im"><span style="color:rgb(34,34,34);font-size:13px;font-family:arial,sans-serif">foo x = case typeOf x of</span><br style="color:rgb(34,34,34);font-size:13px;font-family:arial,sans-serif">


</div><span style="color:rgb(34,34,34);font-size:13px;font-family:arial,sans-serif">          Int  -&gt; (3 :: Int)</span><div class="im"><br style="color:rgb(34,34,34);font-size:13px;font-family:arial,sans-serif">
<span style="color:rgb(34,34,34);font-size:13px;font-family:arial,sans-serif">          Char -&gt; 4</span><br style="color:rgb(34,34,34);font-size:13px;font-family:arial,sans-serif">
<span style="color:rgb(34,34,34);font-size:13px;font-family:arial,sans-serif">          _    -&gt; 5</span><font color="#222222" face="arial, helvetica, sans-serif"><br></font><div><span style="color:rgb(34,34,34);font-size:13px"><font face="arial, helvetica, sans-serif"><br>


</font></span></div></div><div><span style="color:rgb(34,34,34);font-size:13px"><font face="arial, helvetica, sans-serif">This function (ignoring the monomorphism restriction) should be inferred to have the type </font><font face="courier new, monospace">Typeable a =&gt; a -&gt; Int</font></span></div>


<div><span style="color:rgb(34,34,34);font-size:13px"><font face="arial, helvetica, sans-serif"><br></font></span></div><div><span style="color:rgb(34,34,34);font-size:13px"><font face="arial, helvetica, sans-serif">In short, from the language user&#39;s perspective, Typeable should still be a regular old typeclass, that just happens to come with a distinct instance for every type.</font></span></div>


<div><font color="#222222" face="arial, helvetica, sans-serif"><br></font></div><div><font color="#222222" face="arial, helvetica, sans-serif">Another way to model the &quot;danger&quot; of accessing Typeable information is to use a monad, and consider access to Typeable information to be an &quot;effect&quot;.[1] For backwards compatibility, I think it would be easier to just stick with the typeclass.</font></div>


<div><font color="#222222" face="arial, helvetica, sans-serif"><br></font></div><div><font color="#222222" face="arial, helvetica, sans-serif">[1] </font><a href="http://hpaste.org/75824" target="_blank">http://hpaste.org/75824</a><span class="HOEnZb"><font color="#888888"><font color="#222222" face="arial, helvetica, sans-serif"><br>


</font></font></span><div><span class="HOEnZb"><font color="#888888"><br clear="all">-- Dan Burton</font></span><div><div class="h5"><br></div><div class="h5"><span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:13px;background-color:rgb(255,255,255)">Another, simpler alternative (if we don&#39;t want to use the Typeable typeclass or the Monad idea) is to simply prefix &quot;unsafe&quot; to all of the Typeable methods, and then quarentine them to a &quot;contaminated&quot; module as we have done with unsafePerformIO.</span><br>


<br><br><div class="gmail_quote">On Fri, Oct 5, 2012 at 10:12 AM, Simon Peyton-Jones <span dir="ltr">&lt;<a href="mailto:simonpj@microsoft.com" target="_blank">simonpj@microsoft.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">








<div lang="EN-GB" link="blue" vlink="purple">
<div><div>
<p class="MsoNormal" style="margin-left:36.0pt">To take advantage of Typeable, though, the user should still have to annotate the necessary Typeable constraints.<span style="font-size:11.0pt;font-family:&quot;Verdana&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u><u></u></span></p>



<p class="MsoNormal"><span style="font-size:11.0pt;font-family:&quot;Verdana&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u> <u></u></span></p>
</div><p class="MsoNormal"><span style="font-size:11.0pt;font-family:&quot;Verdana&quot;,&quot;sans-serif&quot;;color:#1f497d">Can you say what you mean by this?  Perhaps with an example.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:&quot;Verdana&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:&quot;Verdana&quot;,&quot;sans-serif&quot;;color:#1f497d">Simon<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:&quot;Verdana&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u><u></u></span></p>
<div style="border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm 4.0pt">
<div>
<div style="border:none;border-top:solid #b5c4df 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span lang="EN-US" style="font-size:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;">From:</span></b><span lang="EN-US" style="font-size:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;"> Dan Burton [mailto:<a href="mailto:danburton.email@gmail.com" target="_blank">danburton.email@gmail.com</a>]
<br>
<b>Sent:</b> 05 October 2012 17:05</span></p><div><br>
<b>To:</b> Simon Peyton-Jones<br>
<b>Cc:</b> <a href="mailto:libraries@haskell.org" target="_blank">libraries@haskell.org</a><br>
<b>Subject:</b> Re: Changes to Typeable<u></u><u></u></div><p></p>
</div>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm">
<p class="MsoNormal">Allowing users to write instances leads to potential un-soundness when doing dynamic type casts, so it has always been a Bad Idea.<u></u><u></u></p>
</blockquote><div><div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Related to this, I&#39;m sure several of us remember Bob Harper&#39;s blog post[1] regarding exceptions that uses a hand-written Typeable instance. The ideal scenario would be for the compiler to automatically derive Typeable for all types, and
 completely disallow the user from providing hand-written instances. To take advantage of Typeable, though, the user should still have to annotate the necessary Typeable constraints. Whether this is special-cased in the compiler for optimization is an implementation
 detail and is largely irrelevant to the Haskell programmer; I say let&#39;s follow the common Haskell mentality of making it correct first and fast second.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Most typeclasses come with some &quot;laws&quot; that make them useful; I don&#39;t see any documented laws for Typeable, but presumably there are some (e.g. no type should say it is another type), and the compiler can automatically derive instances
 that are guaranteed to follow them.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">It would be nice to be able to enforce typeclass laws on instances at compile time, but that&#39;s stepping into theorem prover territory.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">[1] <a href="http://existentialtype.wordpress.com/2012/08/14/haskell-is-exceptionally-unsafe/" target="_blank">http://existentialtype.wordpress.com/2012/08/14/haskell-is-exceptionally-unsafe/</a><u></u><u></u></p>



</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">-- Dan Burton<u></u><u></u></p>
</div>
</div></div></div>
</div>
</div>
</div>

</blockquote></div><br></div></div></div></div></div>
</div><br></div>