From mboxrd@z Thu Jan 1 00:00:00 1970 X-Sympa-To: caml-list@inria.fr Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by walapai.inria.fr (8.13.6/8.13.6) with ESMTP id p3TBsObw023443 for ; Fri, 29 Apr 2011 13:54:24 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ar4AAHemuk3RVdW+kWdsb2JhbACYCj+NNAgUAQEBAQkLCwcUBCGIcaEPinyHSTSIY4V+BIYNgwiQBzuDSw X-IronPort-AV: E=Sophos;i="4.64,287,1301868000"; d="scan'208";a="107072493" Received: from mail-yx0-f190.google.com ([209.85.213.190]) by mail1-smtp-roc.national.inria.fr with ESMTP/TLS/RC4-SHA; 29 Apr 2011 13:54:18 +0200 Received: by yxi11 with SMTP id 11so4766956yxi.27 for ; Fri, 29 Apr 2011 04:54:17 -0700 (PDT) Received: by 10.100.18.33 with SMTP id 33mr475999anr.36.1304078057388; Fri, 29 Apr 2011 04:54:17 -0700 (PDT) Path: glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: fa.caml Date: Fri, 29 Apr 2011 04:54:17 -0700 (PDT) In-Reply-To: Reply-To: fa.caml@googlegroups.com Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=132.177.8.40; posting-account=C2cSdAoAAADMDMMNIKs975m9-hquLe4I NNTP-Posting-Host: 132.177.8.40 User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: From: Ethan Burns To: fa.caml@googlegroups.com Cc: Dmitry Bely , caml-list@inria.fr Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by walapai.inria.fr id p3TBsObw023443 X-Validation-by: burns.ethan@gmail.com Subject: Re: [Caml-list] Comparing variant types On Friday, April 29, 2011 5:34:16 AM UTC-4, luc.ma...@inria.fr wrote: > 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. Well, in this case I am actually not really writing the function g and instead this comparison is embedded in another function somewhere. My feeling was that using <> would be perfectly safe because it would translate to an integer comparison. The structure of a type containing only simple constructors should be unique (I think they are all just mapped to ints). > 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 This is tiresome indeed! Also, I am concerned that it is less efficient than just dropping down to compare_val (although I haven't tried it). Since the type that I am using will only ever have a unique representation, I would love to avoid something like this. I think that the solution that I will stick with for now is the one given by Dmitry (although I am typically not a fan of != in general). Fabrice seemed to imply that optimizing <> in this case was 'in the works.' I will be pretty happy to see that because I am sure that I have other code lying around somewhere that is assuming <> on a simple 'enum type' is just an integer comparison. Best, Ethan