Browse thread
[Caml-list] Why must types be always defined at the top level?
[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: | 2004-06-25 (11:08) |
From: | Basile Starynkevitch [local] <basile.starynkevitch@i...> |
Subject: | Re: [Caml-list] Why must types be always defined at the top level? |
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