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 KAA10840; Tue, 3 Feb 2004 10:51:51 +0100 (MET) 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 KAA10511 for ; Tue, 3 Feb 2004 10:51:50 +0100 (MET) Received: from mail5.tpgi.com.au (mail.tpgi.com.au [203.12.160.100]) by concorde.inria.fr (8.11.1/8.11.1) with ESMTP id i139pmP03655 for ; Tue, 3 Feb 2004 10:51:49 +0100 (MET) Received: from 203-219-16-154-syd-ts21-2600.tpgi.com.au (203-219-16-154-syd-ts21-2600.tpgi.com.au [203.219.16.154]) by mail5.tpgi.com.au (8.12.10/8.12.10) with ESMTP id i139pRwH029815; Tue, 3 Feb 2004 20:51:28 +1100 Subject: Re: [Caml-list] Big_int comparisons From: skaller Reply-To: skaller@tpg.com.au To: Alain.Frisch@ens.fr Cc: "Yaron M. Minsky" , Caml List In-Reply-To: References: Content-Type: text/plain Message-Id: <1075801977.17649.87.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4) Date: 03 Feb 2004 20:52:58 +1100 Content-Transfer-Encoding: 7bit X-TPG-Antivirus: Passed X-Loop: caml-list@inria.fr X-Spam: no; 0.00; caml-list:01 tpg:99 2004:99 alain:01 frisch:01 yaron:01 minsky:01 generic:01 non-custom:01 python:01 generic:01 next':01 python:01 functors:01 genericity:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk On Mon, 2004-02-02 at 23:23, Alain.Frisch@ens.fr wrote: > On Sun, 1 Feb 2004, Yaron M. Minsky wrote: > > > Does anyone know why there's no support for Big_int comparisons? > > A solution could be to allow attaching custom generic operations to > non-custom blocks The problem with this is you end up re-implementing Python, i.e. having a 'vector' of generic functions for each type. Another 'useful' generic operator is of course 'get next' for containers (C++ iterators, Python sequence operators ..) Now, Ocaml does provide the tools to deal with this in most cases: functors (provided the genericity is not required to be run-time). The problem then would seem to be that its hard to write functors for every data structure, sub-data structure of the data stucture, etc. At least part of the reason is that the functors provide abstract types, so building a functor to provide, for example, a comparator so you can put them in sets isn't immediately compatible with other generic operations such as pattern matching. It seems like the 'private' keyword is a step forward here: a way to control representation invariants during construction (or mutation) which doesn't prevent convenient algrebraic type destructors like pattern matching being used: even though, in principle, these operations may not retain their semantics, for example a type int * int representing a rational number admits the destructor fst v which is not in fact a projection (since the type is not a product). -- John Max Skaller, mailto:skaller@tpg.com.au snail:25/85c Wigram Rd, Glebe, NSW 2037, Australia. voice:61-2-9660-0850. Checkout Felix: 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