Version française
Home     About     Download     Resources     Contact us    
Browse thread
on polymorphic compare and objects
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Peng Zang <peng.zang@g...>
Subject: Re: [Caml-list] on polymorphic compare and objects
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On Wednesday 03 September 2008 02:31:10 am Alain Frisch wrote:
> Peng Zang wrote:
> > For objects, we require that all objects
> > implement an equal method that satisfies the semantic contract.
>
> How do you ensure that the method is indeed implemented and has the
> correct type?

Currently, I require all objects to inherit from a general "Object" class, 
much like in Java.  If you define an object without the equals method for 
example, or with the wrong type, it will complain that it doesn't match the 
type or a method is unimplemented.  However, the user must manually write 
the "inherit object" line.   I would like to use camlp4 to make this 
automatic, but I have yet to learn camlp4.

> A more robust approach to attaching custom generic operations to
> arbitrary data would be to introduce the equivalent of custom blocks,
> but for OCaml data. This probably amounts to reserving a new GC tag and
> deciding on a memory layout (e.g. a block with this tag has two fields:
> the underlying value and a dictionary of generic functions). Then simple
> modules in stdlib could expose a well-typed interface (ensuring that the
> type of the dictionary's functions is compatible with the type of the
> underlying values). It would even be possible to expose the resulting
> blocks as values of a private record type with two fields, so as to
> preserve pattern matching on the underlying value.

I like this approach too.  When I first encountered the polymorphic compare 
issue, custom blocks looked like a great solution.  I couldn't figure out how 
to make it work though.  Even with the helpful description you provided, I'm 
not sure if I could figure out how to do it.

I ended up making objects fit the bill because objects are all about attaching 
functions to data.  I also like how it gives you structural subtyping which I 
love.  I wish it were more robust, but I think proper enforcement would 
require patching the compiler.

I want to emphasize that the implementation is not the point.  It merely 
serves as a motivating example of the general approach: fix polymorphic 
compare (and similar functions) by giving it dynamic dispatch for objects.  
If this approach is reasonable, and it bears the trial of time, I would like 
to patch the compiler to properly enforce it.

Peng
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.7 (GNU/Linux)

iD8DBQFIvqFafIRcEFL/JewRAnFQAJ9lloSHWcrS/NoOrlSq4cxdxnlq5ACgnbtu
kHDRxpzodXNcdd0G0aerAqY=
=7XTV
-----END PGP SIGNATURE-----