From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by walapai.inria.fr (8.13.6/8.13.6) with ESMTP id p3TBWL7X022595 for ; Fri, 29 Apr 2011 13:32:21 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkEDAJeguk3RVdivkGdsb2JhbACYSY00CBQBAQEBCQkNBxQEIaoOinyCJ4UjNIheAQEDBoV4BIYHiGGKNDuDMA X-IronPort-AV: E=Sophos;i="4.64,287,1301868000"; d="scan'208";a="98332466" Received: from mail-qy0-f175.google.com ([209.85.216.175]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/RC4-SHA; 29 Apr 2011 13:32:16 +0200 Received: by qyk35 with SMTP id 35so260096qyk.6 for ; Fri, 29 Apr 2011 04:32:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=9uXyfVaAx9mjuiR3UJ8KIIcQp/NitYJ01LMRxAlNbro=; b=trHCPGodf/3p8yKumIfhIoF1Sy/M44GRwLawKOykjpwZvA3mOf/2nWuZL2NG8JeRmx ln1dQTFljhlxH0Lg2rMlCViqgcfbkDUPU1T9cxTkdHHbPP5aYzVODGi8LH37y7UdnHj6 vKIpwXs5ytVYD+WzQAvvMP6I2p7fb6VXjxWkM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=gGg2OUUbabXzfPkiD5NyNcqMEM0IXi6gDwFq7c00ZQ24mFV1tJRPbvXjQiRnhv0mSv H+dqoEitgSqPHOw3d+Ilh/DssmNigBrmZFmiF40kuVwMsgJWtCe8BPHNU8uNb9kkTTjb FzyIvFPWUVgedLzAdjYtt9kiDmwZ+DmUTAZV8= MIME-Version: 1.0 Received: by 10.224.195.6 with SMTP id ea6mr3709371qab.304.1304076735056; Fri, 29 Apr 2011 04:32:15 -0700 (PDT) Received: by 10.229.32.1 with HTTP; Fri, 29 Apr 2011 04:32:15 -0700 (PDT) In-Reply-To: <20110429093355.GA25892@yquem.inria.fr> References: <164004794.892685.1304067487325.JavaMail.root@zmbs2.inria.fr> <20110429093355.GA25892@yquem.inria.fr> Date: Fri, 29 Apr 2011 15:32:15 +0400 Message-ID: From: Dmitry Bely To: caml-list@inria.fr Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [Caml-list] Comparing variant types On Fri, Apr 29, 2011 at 1:33 PM, wrote: >> > (* performs a simple comparison *) >> > let f a = a <> Right >> > >> > (* calls out to C to do compare_val *) >> > let g (a:dir) b = a <> b >> > > ... >> >> let g (a:dir) b = a != b >> >> - Dmitry Bely >> > > As a general rule, don't do that! :) (using <> or != > for writing 'g'). > > > For <>, you'll get hurt by data types with non-unique representation > (such as Set), as already pointed out. > It is ok to use structural equality when it is not the case, but > your programm is not as robust as you may want it to be. > > For !=, it is much worse, as soon as you add a non-constant > constructor to your data type, your code is wrong > (cf. [1] != [1]) > > If you aim at robust code. A recommended (tiresome) alternative > is to write your own equality function once for all, in > the following style. > > type dir = Left | Right | Up | Down | No_op > > let dir_equal d1 d2 = match d1,d2 with > | (Left, Left) > | (Right,Right) > | (Up, Up) > | (Down,Down) > | (No_op,No_op) > -> true > | (Left,(Right|Up|Down|No_op)) > | (Right,(Left|Up|Down|No_op)) > | (Up,(Left|Right|Down|No_op)) > | (Down,(Left|Right|Up|No_op)) > | (No_op,(Down|Up|Right|Left)) > -> false Yes, but Ethan's primary concern was efficiency. You dir_equal would hardly fit (I'm afraid it's even more slow than <> because it's translated into switch/case block). But generally speaking, of course robustness is always the first priority. - Dmitry Bely