caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Jacques Garrigue <garrigue@math.nagoya-u.ac.jp>
To: peng.zang@gmail.com
Cc: caml-list@inria.fr
Subject: Re: [Caml-list] polymorphic lists, existential types and asorted other hattery
Date: Wed, 14 Nov 2007 13:48:40 +0900 (JST)	[thread overview]
Message-ID: <20071114.134840.39171294.garrigue@math.nagoya-u.ac.jp> (raw)
In-Reply-To: <200711131227.18910.peng.zang@gmail.com>

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


  parent reply	other threads:[~2007-11-14  4:48 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 [this message]
2007-11-14 12:45   ` Peng Zang

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=20071114.134840.39171294.garrigue@math.nagoya-u.ac.jp \
    --to=garrigue@math.nagoya-u.ac.jp \
    --cc=caml-list@inria.fr \
    --cc=peng.zang@gmail.com \
    /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;
as well as URLs for NNTP newsgroup(s).