[core libraries] RE: Data.Dynamic: Any vs existential

[Dan Doel]

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. :)

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.



On Mon, Mar 10, 2014 at 4:25 PM, Roman Cheplyaka <roma at ro-che.info> wrote:

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