From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Delivered-To: caml-list@yquem.inria.fr Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by yquem.inria.fr (Postfix) with ESMTP id 0ADEFBCA8 for ; Thu, 31 Mar 2005 08:32:56 +0200 (CEST) Received: from first.in-berlin.de (dialin-145-254-055-146.arcor-ip.net [145.254.55.146]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id j2V6Wsjj001218 for ; Thu, 31 Mar 2005 08:32:55 +0200 Received: by first.in-berlin.de (Postfix, from userid 501) id 6FDBDC96B9; Thu, 31 Mar 2005 00:35:29 +0200 (CEST) Date: Thu, 31 Mar 2005 00:35:29 +0200 From: Oliver Bandel To: caml-list@yquem.inria.fr Subject: Re: [Caml-list] Pervasives.compare output type Message-ID: <20050330223528.GC443@first.in-berlin.de> References: <42430B3B.60408@barettadeit.com> <20050330141708.GB18175@yquem.inria.fr> <424ABB87.1020203@barettadeit.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <424ABB87.1020203@barettadeit.com> User-Agent: Mutt/1.5.6i X-Miltered: at concorde with ID 424B9996.001 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; oliver:01 bandel:01 oliver:01 in-berlin:01 caml-list:01 pervasives:01 baretta:01 subtraction:01 subtraction:01 wrote:01 wrote:01 encode:01 integer:01 integer:01 modules:01 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on yquem.inria.fr X-Spam-Status: No, score=0.3 required=5.0 tests=DATE_IN_PAST_06_12, FORGED_RCVD_HELO autolearn=disabled version=3.0.2 X-Spam-Level: On Wed, Mar 30, 2005 at 04:45:27PM +0200, Alex Baretta wrote: > Xavier Leroy wrote: > >It's a historical error. If I were to do it again, I'd use a sum type > >such as your "comparison_result". The current solution allows to use > >(-) (integer subtraction) as the comparison predicate for *small* > >integer arguments, but this doesn't work as a general integer > >comparison because of subtraction wrapping around for large arguments. > >So, there are really no benefits to encode the result of a 3-way > >comparison as an "int". > > > >- Xavier Leroy > > Whether fixing such historical errors engenders more benefits than > trouble is a very interesting philosophical question. Well, there are implementations of modules with and without named parameters, why not providing different implementations for compare? Or maybe additionnally to "compare" provide a function "comparison" or "comp" or something like that? Is it sooooooo necessary to have only this one "compare" function? Is it too much overhead in the interface to add a function that uses sum-types? Maybe commenting "compare" with an attribute like "do not use in future developments" or so?! Ciao, Oliver