English version
Accueil     À propos     Téléchargement     Ressources     Contactez-nous    

Ce site est rarement mis à jour. Pour les informations les plus récentes, rendez-vous sur le nouveau site OCaml à l'adresse ocaml.org.

Browse thread
polymorphic lists, existential types and asorted other hattery
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2007-11-14 (12:45)
From: Peng Zang <peng.zang@g...>
Subject: Re: [Caml-list] polymorphic lists, existential types and asorted other hattery
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 

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,


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

Version: GnuPG v2.0.7 (GNU/Linux)