From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=AWL autolearn=disabled version=3.1.3 Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by yquem.inria.fr (Postfix) with ESMTP id 2C0D4BC6B for ; Thu, 10 Jan 2008 21:07:44 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAO4JhkfAbSoIh2dsb2JhbACQHwEBAQgKKZkt X-IronPort-AV: E=Sophos;i="4.24,267,1196636400"; d="scan'208";a="7655502" Received: from discorde.inria.fr ([192.93.2.38]) by mail3-smtp-sop.national.inria.fr with ESMTP; 10 Jan 2008 21:07:43 +0100 Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by discorde.inria.fr (8.13.6/8.13.6) with ESMTP id m0AK7hpS012431 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=OK) for ; Thu, 10 Jan 2008 21:07:43 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAO4JhkfAbSoIh2dsb2JhbACQHwEBAQgKKZkt X-IronPort-AV: E=Sophos;i="4.24,267,1196636400"; d="scan'208";a="7655501" Received: from einhorn.in-berlin.de ([192.109.42.8]) by mail3-smtp-sop.national.inria.fr with ESMTP; 10 Jan 2008 21:07:43 +0100 X-Envelope-From: oliver@first.in-berlin.de Received: from einhorn.in-berlin.de (localhost [127.0.0.1]) by einhorn.in-berlin.de (8.13.6/8.13.6/Debian-1) with ESMTP id m0AK7baW011034 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 10 Jan 2008 21:07:37 +0100 Received: (from www-data@localhost) by einhorn.in-berlin.de (8.13.6/8.13.6/Submit) id m0AK7bOC011031; Thu, 10 Jan 2008 21:07:37 +0100 X-Authentication-Warning: einhorn.in-berlin.de: www-data set sender to oliver@first.in-berlin.de using -f Received: from dslb-088-073-077-156.pools.arcor-ip.net (dslb-088-073-077-156.pools.arcor-ip.net [88.73.77.156]) by webmail.in-berlin.de (IMP) with HTTP for ; Thu, 10 Jan 2008 21:07:37 +0100 Message-ID: <1199995657.47867b0972262@webmail.in-berlin.de> Date: Thu, 10 Jan 2008 21:07:37 +0100 From: Oliver Bandel To: Thomas Fischbacher Cc: Brian Hurt , Eric Cooper , caml-list@inria.fr Subject: Re: [Caml-list] Annoying behaviour of OCaml References: <4786312A.1050003@functionality.de> <20080110152017.GA513@stratocaster.home> <478639DE.6040903@janestcapital.com> <47863E28.6080803@functionality.de> In-Reply-To: <47863E28.6080803@functionality.de> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.6 X-Scanned-By: MIMEDefang_at_IN-Berlin_e.V. on 192.109.42.8 X-Miltered: at discorde with ID 47867B0F.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; bandel:01 in-berlin:01 ocaml:01 bug:01 ocaml's:01 ocaml:01 wrote:01 oliver:01 oliver:01 caml-list:01 functions:01 functions:01 compares:01 int:01 int:01 Zitat von Thomas Fischbacher : > Brian Hurt wrote: > > >>This is indeed unexpected behavior: > >> # compare "123" "45";; > >> - : int = -1 > >> # compare [1;2;3] [4;5];; > >> - : int = -1 > >> # compare [|1;2;3|] [|4;5|];; > >> - : int = 1 > >> > > It it? I mean, all I ever read into compare was that it returned a > > *consistent* ordering- for example, if a < b and b < c, then a < c. > > Well, yes, this is what the manual says and guarantees. However, > everybody Can you prove "everybody"? Even if this would be the case, not what we expect is of importance, but what the documentation says. If there's a difference between documentation and bahaviour, then there is a bug (in the documentation, or in the implementation, or both). > does expect lexicographical ordering here. In particular, > it would be natural to have > > compare (Array.of_list x) (Array.of_list y) = compare x y Well, this is one way one could expect it. But there might be reasons not to do so. This is mixig two paradigms, and so this might be used differently. The same is when using strings: OCaml's strings aren't functional. You can change them in-place. This is not following purely functional style, but that's not what OCaml is prtends to provide. I normally write my comparison functions by myself, to extract the elements of a datastructure that should be comapred, but then use comapre on it (even if other functions might be faster). If I would compare more complex data structures, I would look into the documentation. I also was surprised on that language-comparison, but now slightly remember, this was mentioned on this list before. Look here, compare [|1;2;3;5|] [|1;2;3;4|];; - : int = 1 # compare [|1;2;3;4|] [|1;2;3;5|];; - : int = -1 # Nice. If the size is equal, it compares "as expected". :-) Isn't that enough? ;-) Now it's clear, how to write your own function ;-) > > As this does not hold (see above), this is an unexpected pitfall. That's your opinion. There might be other opinions on it. I would say, it's a design-decision. And apparantly different then you would do it. Ciao, Oliver