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=1.3 required=5.0 tests=AWL,DNS_FROM_RFC_ABUSE, DNS_FROM_RFC_POST autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by yquem.inria.fr (Postfix) with ESMTP id 81779BC6C for ; Wed, 6 Feb 2008 09:22:04 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAADT9qEfAXQInh2dsb2JhbACBWY5YAQEBCAopgRWcDw X-IronPort-AV: E=Sophos;i="4.25,311,1199660400"; d="scan'208";a="22277039" Received: from concorde.inria.fr ([192.93.2.39]) by mail4-smtp-sop.national.inria.fr with ESMTP; 06 Feb 2008 09:22:04 +0100 Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by concorde.inria.fr (8.13.6/8.13.6) with ESMTP id m168M3Ph009647 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=OK) for ; Wed, 6 Feb 2008 09:22:03 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAPz8qEfUGyoji2dsb2JhbACBWY5YAQEBCAQGCQgRB4EVnBA X-IronPort-AV: E=Sophos;i="4.25,311,1199660400"; d="scan'208";a="7689691" Received: from smtp5-g19.free.fr ([212.27.42.35]) by mail1-smtp-roc.national.inria.fr with ESMTP; 06 Feb 2008 09:22:03 +0100 Received: from smtp5-g19.free.fr (localhost.localdomain [127.0.0.1]) by smtp5-g19.free.fr (Postfix) with ESMTP id F371F3F61B3; Wed, 6 Feb 2008 09:22:02 +0100 (CET) Received: from Llea.celt.neu (ron34-3-82-236-236-194.fbx.proxad.net [82.236.236.194]) by smtp5-g19.free.fr (Postfix) with ESMTP id 7B52E3F6181; Wed, 6 Feb 2008 09:22:02 +0100 (CET) Received: from Llea.celt.neu (localhost [127.0.0.1]) by Llea.celt.neu (8.14.2/8.13.8) with ESMTP id m168Lm01001053; Wed, 6 Feb 2008 09:21:48 +0100 (CET) (envelope-from michaelgrunewald@yahoo.fr) Received: (from michael@localhost) by Llea.celt.neu (8.14.2/8.13.8/Submit) id m168Llcd001052; Wed, 6 Feb 2008 09:21:47 +0100 (CET) (envelope-from michaelgrunewald@yahoo.fr) X-Authentication-Warning: Llea.celt.neu: michael set sender to michaelgrunewald@yahoo.fr using -f To: "Damien Guichard" Cc: "Liste de diffusion OCaml" Subject: Re: [Caml-list] Variants & structural ordering References: <20080205081845.2D24D1C02531@mwinf2341.orange.fr> From: michaelgrunewald@yahoo.fr (=?iso-8859-15?Q?Micha=EBl_Gr=FCnewald?=) Date: Wed, 06 Feb 2008 09:21:47 +0100 In-Reply-To: <20080205081845.2D24D1C02531@mwinf2341.orange.fr> (Damien Guichard's message of "Tue\, 5 Feb 2008 09\:21\:21 +0100") Message-ID: <864pcmze90.fsf@Llea.celt.neu> User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: quoted-printable X-Miltered: at concorde with ID 47A96E2B.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; variants:01 damien:01 guichard:01 ocaml:01 work-around:01 bug:01 ocaml:01 vice-versa:01 caml-list:01 int:01 int:01 writes:01 conventions:02 arbitrary:02 define:02 "Damien Guichard" writes: > Hi everybody, >=20=20 > Typically, when you declare: >=20=20 > type card =3D > | Card of int > | Jack > | Queen > | King > | Ace > ;; >=20=20 > The relation you wish is: >=20=20 > Card(2) < ...< Card(10) < Jack < Queen < King < Ace >=20=20 > And that's what you get when using F#. >=20=20 > However when using OCaml here is what you get: >=20=20 > Jack < Queen < King < Ace < Card(2) < ...< Card(10) >=20=20 > And the work-around is: >=20=20 > type card =3D > | Card of int > | Jack of unit > | Queen of unit > | King of unit > | Ace of unit > ;; >=20=20 > Is this a bug or a feature ? > Will it change in a foreseable future ? Conventions are always a bit arbitrary, aren't they? To me, the natural order with cards are: Card(7) < Card(8) < Queen < King < Card(10)< Ace < Card(9) < Jack and Card(7) < Card(8) < Card(9) < Jack < Queen < King < Card(10)< Ace (yes there are two natural orders). Furthermore, I tried your program on a host whose native charset is KOBAIA-8 (a weird variation on EBCDIC), hold your breath: F# behaves there just like OCaml does on your host, and vice-versa! Computers are good at doing what they are told to, so why don't you tell them? The only purpose of a generic `compare' procedure os the easy use of `Set.Make' and `Map.Make' with random types, isnt't it? It is very bad to assume it giving any sensible order on non basic types, you sure have to define `sensible' yourself. --=20 Micha=EBl