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 MAA08896; Fri, 25 Jun 2004 12:20:37 +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 MAA08899; Fri, 25 Jun 2004 12:20:36 +0200 (MET DST) Received: from smtp1.adl2.internode.on.net (smtp1.adl2.internode.on.net [203.16.214.181]) by concorde.inria.fr (8.12.10/8.12.10) with ESMTP id i5PAKWSH006117; Fri, 25 Jun 2004 12:20:34 +0200 Received: from [192.168.1.200] (ppp215-31.lns1.syd2.internode.on.net [203.122.215.31]) by smtp1.adl2.internode.on.net (8.12.9/8.12.9) with ESMTP id i5PAKQ4Y076139; Fri, 25 Jun 2004 19:50:27 +0930 (CST) Subject: RE: [Caml-list] Why must types be always defined at the top level? From: skaller Reply-To: skaller@users.sourceforge.net To: jfh@cs.brown.edu Cc: "'Xavier Leroy'" , "'caml-list'" In-Reply-To: <20040624194603.2A91010EF06@clark.cs.brown.edu> References: <20040624194603.2A91010EF06@clark.cs.brown.edu> Content-Type: text/plain Message-Id: <1088158825.1941.113.camel@pelican.wigram> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4) Date: 25 Jun 2004 20:20:26 +1000 Content-Transfer-Encoding: 7bit X-Miltered: at concorde with ID 40DBFC70.001 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Loop: caml-list@inria.fr X-Spam: no; 0.00; caml-list:01 sourceforge:01 2004:99 bignums:01 hash:01 hashtable:01 hashtable:01 hash:01 opaque:01 9660:01 glebe:01 ints:01 ocaml:01 sml:01 nsw:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk 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 :( 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. 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) Is there a way to use an address as a comparable but otherwise opaque value? -- John Skaller, mailto:skaller@users.sf.net voice: 061-2-9660-0850, snail: PO BOX 401 Glebe NSW 2037 Australia Checkout the Felix programming language http://felix.sf.net ------------------- 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