From: Peng Zang <peng.zang@gmail.com>
To: caml-list@inria.fr
Subject: Re: [Caml-list] polymorphic lists, existential types and asorted other hattery
Date: Wed, 14 Nov 2007 07:45:25 -0500 [thread overview]
Message-ID: <200711140745.29151.peng.zang@gmail.com> (raw)
In-Reply-To: <20071114.134840.39171294.garrigue@math.nagoya-u.ac.jp>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Wow, alright. First I want to thank everyone for replying to my post. You
guys have been extremely helpful and I have definitely gained a better
understanding of this issue.
Jacques, your explanation of how existential types are really just a way of
encoding objects helps me understand both a lot better. I never understood
the connection before. I also appreciate your tip on speeding up method
calls.
Arnaud, your trick for encoding existencial types is fascinating. I haven't
followed through your reference thread through yet, but I'm sure I'll be
doing that later today.
Dmitri and Benjamin, the OO examples and benchmarking makes it clear to me
that objects can be quite fast. I don't know where I read about objects
being slow but that's clearly not the case here.
Overall I think the OO solution is what I am looking for. I had been under
the impression that OO was slower and that it was some thing unpleasant from
various readings (eg. Yaron Minsky's summary
http://www.haskell.org/sitewiki/images/0/03/TMR-Issue7.pdf [pg. 30])
Perhaps however, I have been getting the wrong impression. I am going to
rework my code base using objects and see how it turns out. On this note,
does anyone know of a way to automatically generate the object of a module?
Ie. I have three modules A,B and C which all implement the same module type
X, but I really want three objects a,b and c for those modules which
implement the same class type x, so that I can stick all objects in the same
list and map over them etc..
I can do this by hand (not difficult, just a little tedious), but I wonder if
there's not some camlp4 trick that can take the values in a module and just
create a passthrough object which exposes those values.
Thanks again for all your replies. They have helped enormously,
Peng
On Tuesday 13 November 2007 11:48:40 pm Jacques Garrigue wrote:
> From: Peng Zang <peng.zang@gmail.com>
>
> > I've come across a way to do this in haskell using what they call
> > "existential types".
> >
> > http://www.haskell.org/haskellwiki/Existential_type
> >
> > I don't really understand existential types however and don't know if
> > OCaml has them nor how to use them.
>
> Notwithstanding your reluctance to use them, objects in ocaml are
> really what amounts to Haskell's existential types, particularly
> those for which a type class is specified. Put the other way round,
> most examples of constrained existential types (i.e. where there is a
> type class specifiying the existential) are just encodings for
> objects. The encoding of objects through existentials has been known
> for a long time. OCaml doesn't need this encoding because it has
> primitive objects.
>
> From an implementation point of view, constrained existentials need to
> be accompanied by their dictionaries, which is exactly the same thing
> as the method table in an object, so even the implementation is very
> similar.
>
> Method calls on arbitrary objects can be slow. This is because, due to
> subtyping, in some situations there is no way to know where the method
> will be in the table, and a binary search has to be done. However,
> this overhead can be avoided if all objects used in a specific method
> call have the same methods. That is, they should have the same
> interface, without using subtyping. That way, the method will be at
> the same position in all objects, and this position is cached (for
> native code).
> (Note that this also means that any benchmark on the performance of
> objects shall consider the impact of cacheing, which can be hard to
> evaluate in micro-benchmarks.)
>
> Dmitri's example had this property, so it should display good
> performance (as good as explicit existential encodings.)
>
> Jacques Garrigue
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.7 (GNU/Linux)
iD8DBQFHOu3pfIRcEFL/JewRAnwXAKCqWM5BJ6J44jXMHzmonP5iRhqUtgCgoq6/
rg54JaQONgB/DCVf4RP4aPc=
=NP4X
-----END PGP SIGNATURE-----
prev parent reply other threads:[~2007-11-14 12:45 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-11-13 17:27 Peng Zang
2007-11-13 18:02 ` [Caml-list] " Arnaud Spiwack
2007-11-13 18:29 ` Julien Moutinho
2007-11-13 18:35 ` Julien Moutinho
2007-11-13 21:14 ` Dmitri Boulytchev
2007-11-13 18:24 ` Peng Zang
2007-11-13 21:39 ` Dmitri Boulytchev
2007-11-13 19:13 ` Benjamin Canou
2007-11-14 4:48 ` Jacques Garrigue
2007-11-14 12:45 ` Peng Zang [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200711140745.29151.peng.zang@gmail.com \
--to=peng.zang@gmail.com \
--cc=caml-list@inria.fr \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox