Re: [Caml-list] Why must types be always defined at the top level?

["Basile Starynkevitch [local]" <basile.starynkevitch@inria.fr>]

On Fri, Jun 25, 2004 at 08:20:26PM +1000, skaller wrote:
> On Fri, 2004-06-25 at 05:46, John Hughes wrote:
> > Thanks for the answers.  
> > > > 1. Why no eqtypes? 
> > > 
> > > Eqtypes have been hotly debated even among the SML designers. 

> Hmm .. but interesting Ocaml has a slot to marshal abstract types
> .. and to finalise them .. but not to compare them. Bignums in
> particular don't work with polymorphic compare or hash, which means
> you can't for example use them as keys to a hashtable .. as I just
> discovered again :(

(there is no slot in custom data to support Ocaml values inside them
neither)


> Any thoughts on a way to fix that?

> My hashtable keys are terms which might contain integers which
> happen to be represented by big ints, so just using a custom
> hashtable won't work.

The latest Ocaml CVS has probably some "better" bignums - but I don't
know the details.


> In this case, I'd be more than happy to just hash the term's address
> (this would be heaps faster than the recursive polymorphic
> comparison)

This certainly won't work: addresses (even of opaque types) may move,
because on some occasions (minor GC, compactions) the Ocaml runtime
system (actually the garbage collector part) moves Ocaml values, so
their addresses is changed. To grant your wish (which I actually share
with you) would require to add into the runtime system some kind of
new tag for associative tables, and in several parts of the GC (those
scanning, copying or moving values) additional code to handle it.

IMHO hashtables of (polymorphic) mutable values don't work, even when
using physical identity (==) as the equality test, because their
hashes (which is not based upon the address) changes with tehir
content.

Probably encapsulating such values (or just your bignums) inside
object should work, since objects have immutable identities and
hashcodes.


> Is there a way to use an address as a comparable
> but otherwise opaque value?

No, see above. But try to encapsulate them in objects (at least for
the hash table) might help. Of course, you might need to "hash-cons"
or cache the containing object...

-- 
Basile STARYNKEVITCH -- basile dot starynkevitch at inria dot fr
Project cristal.inria.fr - (temporarily)
http://cristal.inria.fr/~starynke --- all opinions are only mine 

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners