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 4B067BC84 for ; Wed, 30 Mar 2005 16:17:14 +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 j2UEHDlI002507 for ; Wed, 30 Mar 2005 16:17:14 +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 QAA32510 for ; Wed, 30 Mar 2005 16:17:13 +0200 (MET DST) Received: from yquem.inria.fr (yquem.inria.fr [128.93.8.37]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id j2UEHC9d002503; Wed, 30 Mar 2005 16:17:12 +0200 Received: by yquem.inria.fr (Postfix, from userid 18180) id A9653BC84; Wed, 30 Mar 2005 16:17:12 +0200 (CEST) Date: Wed, 30 Mar 2005 16:17:12 +0200 From: Xavier Leroy To: Alex Baretta Cc: Ocaml Subject: Re: [Caml-list] Pervasives.compare output type Message-ID: <20050330141708.GB18175@yquem.inria.fr> References: <42430B3B.60408@barettadeit.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42430B3B.60408@barettadeit.com> User-Agent: Mutt/1.3.28i X-Miltered: at nez-perce with ID 424AB4E9.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Miltered: at nez-perce with ID 424AB4E8.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; caml-list:01 pervasives:01 pervasives:01 intuitively:01 subtraction:01 subtraction:01 encode:01 integer:01 integer:01 int:01 int:01 output:02 comparison:03 comparison:03 i'd:05 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: > Pervasives.compare currently returns an int. Intuitively it would be > more appropriate for it to return a union type such as the following. > type comparison_result = Less | Equals | Greater > What are the reasons behind the present design choice? 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