From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Delivered-To: caml-list@yquem.inria.fr Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by yquem.inria.fr (Postfix) with ESMTP id 78B65BCAE for ; Thu, 30 Jun 2005 14:57:50 +0200 (CEST) Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id j5UCvn7U021288 for ; Thu, 30 Jun 2005 14:57:50 +0200 Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id OAA17266 for ; Thu, 30 Jun 2005 14:57:49 +0200 (MET DST) Received: from [128.93.11.101] (buzet.inria.fr [128.93.11.101]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id j5UCvm70021281 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 30 Jun 2005 14:57:49 +0200 Message-ID: <42C3EC4C.50904@inria.fr> Date: Thu, 30 Jun 2005 14:57:48 +0200 From: Alain Frisch User-Agent: Debian Thunderbird 1.0 (X11/20050116) X-Accept-Language: en-us, en MIME-Version: 1.0 To: padiolea@irisa.fr Cc: Christophe TROESTLER , "O'Caml Mailing List" Subject: Re: [Caml-list] Type abstraction and (polymorphic) equality References: <20050629.023111.15476874.debian00@tiscali.be> <42C3E362.6070606@inria.fr> <42164.131.254.50.45.1120134741.squirrel@mail.irisa.fr> In-Reply-To: <42164.131.254.50.45.1120134741.squirrel@mail.irisa.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Miltered: at nez-perce with ID 42C3EC4D.002 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Miltered: at nez-perce with ID 42C3EC4C.001 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; frisch:01 frisch:01 caml-list:01 abstraction:01 irisa:01 hardcoded:01 compiler:01 runtime:01 compiler:01 runtime:01 wrote:01 equality:01 polymorphic:01 polymorphic:01 pps:01 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on yquem.inria.fr X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.0.2 X-Spam-Level: padiolea@irisa.fr wrote: > I know many people who have "defunctorized" the Map and Set modules > and hardcoded a call to the generic compare to be able to use > Set and Map as easily as you use List. > Even with this generic compare those Set and Map seems quite good > enough (and far better of course that using List for representing > sets and associations). By "good", you mean "efficient", I guess. I understand that easy solutions are sometimes good enough. My claim is that in this case, the easy solution is also a risky one. An example of how using the easy solution can bite you: http://pauillac.inria.fr/bin/caml-bugs/fixed?id=2916 >>You know better than the compiler and the runtime >>system how your data is to be compared, > > > Well then you are perhaps agree with the C++ folks who think > that they better know how to manage memory than the compiler and runtime > system. No, I don't agree. I know that the runtime system can help me managing the memory. There are exceptions (I know that I need to clear explicitly some global tables or references to avoid memory leaks), but in general, the runtime system does a good job and the GC behavior is always safe, so there is no problem using it. Concerning comparisons, you currently need to choose either to rely purely on the generic function or to implement a custom one yourself. You cannot use your knowledge to improve the automatic behavior. The generic comparison is not always safe, so when you write polymorphic code, you simply cannot assume that generic comparison is ok. (I don't claim that the current situation is satisfactory, only that considering it, generic comparison is too dangerous.) >>There are several tools to >>generate automatically comparison functions from type declarations. > > > Which one ? I know Tywith but it is not in the standard distribution > and it requires camlp4 and there is sometimes some annoying > behaviour when you use camlp4 (such as backtraces that points > to wrong information) http://www.pps.jussieu.fr/~maurel/programmation/ -- Alain