<div dir="ltr">I'm open to moving Tagged into base with 7.10. Since it'll make the resultant code less likely to break for artificial reasons involving lifting, etc. and as it is mostly an internal API anyways, I don't have much I can say against it.<div>
<div><br></div><div>Though that said, my poor tagged package will have had its innards slurped out one module at time over the course of years. ;)<div><br></div><div>-Edward</div></div></div></div><div class="gmail_extra">
<br><br><div class="gmail_quote">On Mon, Mar 10, 2014 at 4:49 PM, Simon Peyton Jones <span dir="ltr"><<a href="mailto:simonpj@microsoft.com" target="_blank">simonpj@microsoft.com</a>></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>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Verdana","sans-serif";color:#1f497d">It’s certainly true that, with the current setup, a monomorphic instance will look like<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Verdana","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p><span>instance Typeable Foo where<u></u><u></u></span></p>
<p><span> typeRep# = \_ -> (...something...) :: TypeRep<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Verdana","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Verdana","sans-serif";color:#1f497d">and the optimiser will float the (...something...) to top level. But this is an optimisation, not true by construction. For example,
a non-top-level instance might look like<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Verdana","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p><span>instance (Typeable a, Typeable b) => Typeable (a b) where</span><span lang="EN-US"><u></u><u></u></span></p>
<p><span lang="EN-US"> typeRep</span><span># = \_ -> mkAppTy (typeRep# (undefined::Proxy a))<u></u><u></u></span></p>
<p><span> (typeRep# (undefined :: Proxy b))<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Verdana","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Verdana","sans-serif";color:#1f497d">And that in turn will become<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Verdana","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p><span>$dfTyApp = /\a b. \(d1::Typeable a) (d2::Typeable b).<u></u><u></u></span></p>
<p><span> \_ -> mkAppTy (d1 a) (d2 b)<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Verdana","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Verdana","sans-serif";color:#1f497d">(I’m missing out some newtypes etc.) Now, will the (d1 a) and (d2 b) be floated outside the \_? Not so certain. It depends on
the let-floater.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Verdana","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Verdana","sans-serif";color:#1f497d">The good thing about the Tagged stuff is that there is no lambda in the first place, so the issue doesn’t arise.
<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Verdana","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Verdana","sans-serif";color:#1f497d">It’s ok if the programming interface is less easy to use; Data.Typeable.typeOf is already a function, not a method. The method is
called typeRep#, and is internal.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Verdana","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Verdana","sans-serif";color:#1f497d">So I think you can go ahead and improve the design. But it’s clearly a library-committee decision; I’ll just do what you say.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Verdana","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Verdana","sans-serif";color:#1f497d">Simon<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Verdana","sans-serif";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 #e1e1e1 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif"">From:</span></b><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif""> Libraries [mailto:<a href="mailto:libraries-bounces@haskell.org" target="_blank">libraries-bounces@haskell.org</a>]
<b>On Behalf Of </b>Dan Doel<br>
<b>Sent:</b> 10 March 2014 18:02<br>
<b>To:</b> Roman Cheplyaka<br>
<b>Cc:</b> Haskell Libraries</span></p><div class=""><br>
<b>Subject:</b> Re: Data.Dynamic: Any vs existential<u></u><u></u></div><p></p>
</div>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<div>
<p class="MsoNormal" style="margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
On Mon, Mar 10, 2014 at 6:35 AM, Roman Cheplyaka <<a href="mailto:roma@ro-che.info" target="_blank">roma@ro-che.info</a>> wrote:<u></u><u></u></p><div><div class="h5">
<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" style="margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
Ok, one reason is that the TypeRep won't be cached in the Dynamic value.<br>
Even in GHC 7.8 Typeable is defined as<br>
<br>
class Typeable a where<br>
typeRep# :: Proxy# a -> TypeRep<br>
<br>
instead of<br>
<br>
class Typeable a where<br>
typeRep :: Tagged a TypeRep<br>
<br>
Why? Is this an oversight?<u></u><u></u></p>
</blockquote>
<div>
<p class="MsoNormal" style="margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
<u></u> <u></u></p>
<div>
<p class="MsoNormal" style="margin-right:0cm;margin-bottom:12.0pt;margin-left:0cm">
<span style="font-family:"Arial","sans-serif"">I talked with Ed about this, and he noted that this might be a false problem. Certainly, the Proxy# is never actually used, so as long as the generated instances are of the form:<u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-right:0cm;margin-bottom:12.0pt;margin-left:0cm">
<span style="font-family:"Arial","sans-serif""> typeRep# = let tr = ... in \_ -> tr<br>
<br>
the TypeReps are shared, and are at most a bit of indirection away. Also, how different are (Tagged tr :: Tagged a TypeRep) and ((\_ -> tr) :: Proxy# a -> TypeRep) at a low level? I know the constructor of the former disappears in core, but don't know what
specifically happens with 0-width fields like Proxy#. Is the latter slightly less efficient? If so, can the optimizer eliminate the difference for cases like this?<u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
<span style="font-family:"Arial","sans-serif"">-- Dan<u></u><u></u></span></p>
</div>
</div>
</div>
</div></div></div>
</div>
</div>
</div>
</div>
<p></p>
-- <br><div class="HOEnZb"><div class="h5">
You received this message because you are subscribed to the Google Groups "haskell-core-libraries" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an email to <a href="mailto:haskell-core-libraries+unsubscribe@googlegroups.com" target="_blank">haskell-core-libraries+unsubscribe@googlegroups.com</a>.<br>
For more options, visit <a href="https://groups.google.com/d/optout" target="_blank">https://groups.google.com/d/optout</a>.<br>
</div></div></blockquote></div><br></div>