From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id NAA11071; Fri, 25 Jun 2004 13:08:20 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id NAA11048 for ; Fri, 25 Jun 2004 13:08:19 +0200 (MET DST) Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35]) by concorde.inria.fr (8.12.10/8.12.10) with ESMTP id i5PB8ISH012806 for ; Fri, 25 Jun 2004 13:08:18 +0200 Received: from bourg.inria.fr (bourg.inria.fr [128.93.11.100]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id NAA11315 for ; Fri, 25 Jun 2004 13:08:18 +0200 (MET DST) Received: from basile by bourg.inria.fr with local (Exim 4.34) id 1BdoYe-0000j4-AE for caml-list@inria.fr; Fri, 25 Jun 2004 13:07:48 +0200 Date: Fri, 25 Jun 2004 13:07:48 +0200 To: skaller Subject: Re: [Caml-list] Why must types be always defined at the top level? Message-ID: <20040625110748.GB2707@bourg.inria.fr> References: <20040624194603.2A91010EF06@clark.cs.brown.edu> <1088158825.1941.113.camel@pelican.wigram> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <1088158825.1941.113.camel@pelican.wigram> User-Agent: Mutt/1.5.6+20040523i From: "Basile Starynkevitch [local]" X-Miltered: at concorde with ID 40DC07A2.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Loop: caml-list@inria.fr X-Spam: no; 0.00; caml-list:01 basile:01 basile:01 2004:99 2004:99 bignums:01 hash:01 hashtable:01 hashtable:01 bignums:01 hash:01 opaque:01 runtime:01 runtime:01 hashtables:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk 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