<div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">Note, I'm not proposing that we change Typeable to match my vision. I just think that it is (closer to) an ideal formulation, and the existential Dynamic is closer to it, and thus good. :)<br>
<br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">Changing the definition of Dynamic should have about 0 cost API-wise, which makes it a no brainer. The same can't be said for the rest of my ideal Typeable, though, which probably rules it out.<br>
<br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Mar 10, 2014 at 4:25 PM, Roman Cheplyaka <span dir="ltr"><<a href="mailto:roma@ro-che.info" target="_blank">roma@ro-che.info</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Right — I misunderstood what Dan meant on the first reading.<br>
<br>
Then it's an even more drastic change to Typeable. And it's not clear (to me, at<br>
least) how it should work.<br>
<br>
* Carter Schonwald <<a href="mailto:carter.schonwald@gmail.com">carter.schonwald@gmail.com</a>> [2014-03-10 16:04:21-0400]<br>
<div class="HOEnZb"><div class="h5">> isn't it a GADT/singleton/data family more than a phantom?<br>
><br>
><br>
><br>
><br>
> On Mon, Mar 10, 2014 at 2:09 PM, Roman Cheplyaka <<a href="mailto:roma@ro-che.info">roma@ro-che.info</a>> wrote:<br>
><br>
> > Adding a phantom type to TypeRep itself will break a lot of code (the<br>
> > untyped<br>
> > TypeRep is used quite a bit) without any real benefit (it's essentially<br>
> > the same<br>
> > as Tagged a TypeRep).<br>
> ><br>
> > * Carter Schonwald <<a href="mailto:carter.schonwald@gmail.com">carter.schonwald@gmail.com</a>> [2014-03-10 13:44:13-0400]<br>
> > > +++++1000 to dan doels strawman suggestion.<br>
> > ><br>
> > > I'm a huge fan of indexed types style apis like that one.<br>
> > ><br>
> > ><br>
> > > On Mon, Mar 10, 2014 at 11:54 AM, Dan Doel <<a href="mailto:dan.doel@gmail.com">dan.doel@gmail.com</a>> wrote:<br>
> > ><br>
> > > > On Mon, Mar 10, 2014 at 7:26 AM, Simon Peyton Jones <<br>
> > <a href="mailto:simonpj@microsoft.com">simonpj@microsoft.com</a><br>
> > > > > wrote:<br>
> > > ><br>
> > > >> Dear Core Libraries committee<br>
> > > >><br>
> > > >> I think Roman is right here. Moreover we have known this for at least<br>
> > I<br>
> > > >> think seven years<br>
> > > >> <a href="http://comments.gmane.org/gmane.comp.lang.haskell.cafe/20097" target="_blank">http://comments.gmane.org/gmane.comp.lang.haskell.cafe/20097</a>, where I<br>
> > > >> wrote:<br>
> > > >><br>
> > > >> | Yes, Dynamic preceded the Typeable class, I think.<br>
> > > >> | Were we to do it today, I think we'd have<br>
> > > >> |<br>
> > > >> | data Dynamic = forall a . (Typeable a) => Dynamic a<br>
> > > >> |<br>
> > > >> | Whether it's worth changing, I'm not sure. It's a library so,<br>
> > > >> | if a change desirable, anyone could take a lead.<br>
> > > >><br>
> > > >> The new representation for Dynamic would be good because it's less<br>
> > > >> insecure than all this "Obj" nonsense, instead relying on Typeable,<br>
> > which<br>
> > > >> is pretty good these days.<br>
> > > >><br>
> > > >> Pedro is the most recent visitor to this territory and may have views.<br>
> > > >><br>
> > > >> Roman's point about the method for the Typeable class is a good one<br>
> > too,<br>
> > > >> and not one I've seen discussed.<br>
> > > >><br>
> > > >> Over to you<br>
> > > >><br>
> > > ><br>
> > > > I, at least, am in favor of this. I've thought for a while that the<br>
> > ideal<br>
> > > > form of all this is something like:<br>
> > > ><br>
> > > > data TypeRep a -- indexed by a<br>
> > > ><br>
> > > > class Typeable a where<br>
> > > > typeRep :: TypeRep a<br>
> > > ><br>
> > > > data Dynamic = forall a. Dynamic (TypeRep a) a<br>
> > > ><br>
> > > ><br>
> > > > Where, ideally, TypeRep is an indexed type, and you can match on it to<br>
> > > > refine its argument. Then Typeable just becomes the implicit version of<br>
> > > > this evidence, for convenience. TypeRep versions of cast would also<br>
> > have to<br>
> > > > be primitive probably (since one can not, a priori, enumerate the<br>
> > diagonal<br>
> > > > of all possible monotypes, now and in the future).<br>
> > > ><br>
> > > > Anyhow, I don't know if this entire interface is or will be<br>
> > implementable<br>
> > > > in GHC (the idea comes from a document about JHC way back, although I<br>
> > don't<br>
> > > > know if even it implements this), but using Typeable in an existential<br>
> > > > captures the Dynamic part of it, at least.<br>
> > > ><br>
> > > > Also, I hadn't seen the Tagged version of Typeable before (and hadn't<br>
> > > > thought of it myself). I expect it's an oversight that this wasn't the<br>
> > form<br>
> > > > chosen, as it seems superior to me. In fact, it seems like every<br>
> > situation<br>
> > > > where the 0-width Proxy# could be used, Tagged could also be used<br>
> > instead,<br>
> > > > and is automatically 0-width, and has better sharing behavior? Unless<br>
> > you<br>
> > > > explicitly don't want sharing, that is.<br>
> > > ><br>
> > > > It seems like any relative inconvenience could probably be alleviated<br>
> > by<br>
> > > > the proxy function in tagged, while keeping the nicer behavior.<br>
> > > ><br>
> > > > -- Dan<br>
> > > ><br>
> > > > _______________________________________________<br>
> > > > Libraries mailing list<br>
> > > > <a href="mailto:Libraries@haskell.org">Libraries@haskell.org</a><br>
> > > > <a href="http://www.haskell.org/mailman/listinfo/libraries" target="_blank">http://www.haskell.org/mailman/listinfo/libraries</a><br>
> > > ><br>
> > > ><br>
> ><br>
> > > _______________________________________________<br>
> > > Libraries mailing list<br>
> > > <a href="mailto:Libraries@haskell.org">Libraries@haskell.org</a><br>
> > > <a href="http://www.haskell.org/mailman/listinfo/libraries" target="_blank">http://www.haskell.org/mailman/listinfo/libraries</a><br>
> ><br>
> ><br>
</div></div></blockquote></div><br></div>