From mboxrd@z Thu Jan  1 00:00:00 1970
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 p3SL7khb022589
	for <caml-list@sympa-roc.inria.fr>; Thu, 28 Apr 2011 23:07:46 +0200
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AogBAOTVuU3RVdY2kGdsb2JhbACYIY1cCBQBAQEBCQkNBxQEIYhwoWOKfIInhTM0iF4BAQMGhXAEjlyFHoUKO4Mo
X-IronPort-AV: E=Sophos;i="4.64,282,1301868000"; 
   d="scan'208";a="107023065"
Received: from mail-bw0-f54.google.com ([209.85.214.54])
  by mail1-smtp-roc.national.inria.fr with ESMTP/TLS/RC4-SHA; 28 Apr 2011 23:07:41 +0200
Received: by bwz12 with SMTP id 12so5385436bwz.27
        for <caml-list@inria.fr>; Thu, 28 Apr 2011 14:07:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=gamma;
        h=domainkey-signature:cc:message-id:from:to:in-reply-to:content-type
         :content-transfer-encoding:mime-version:subject:date:references
         :x-mailer;
        bh=sV2siugzIzICM/x4EgKyBzs7WuNnk8dAXRl/Oh8WjKo=;
        b=nqII+Q37Hjn9m/P8Xu5Szdu2oLm5yE//XjAaEa7iUf6Mu/zBUpzMknvgeA04K6p2HR
         4I8dwy2mwZhX6/xsY7ADombpM5YtuotkIwKXJXviwTMCqKBfJ1B4+luxu3ZgOcuZt8Ws
         P4Wtz9C+h6xzmCCF34BHQX9jdAdEzHfCIuGw4=
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=cc:message-id:from:to:in-reply-to:content-type
         :content-transfer-encoding:mime-version:subject:date:references
         :x-mailer;
        b=CCKFjANOB0OnRjrEP5Yfxa8sMkpSZhgKwEw8Qpt4t4kaeKPvf4bgMCJSkHneoNrdDV
         PE7fBEEoomFGkKP4Q9NS/BgmT8MnuCiovfCdfjko3GwzSNGRXH2P7V3M8r5nSbJi7i3Y
         xKVDc3a90mG9h7bD22gRJBMStxq0Xh48fX3ko=
Received: by 10.204.151.202 with SMTP id d10mr1194689bkw.168.1304024860877;
        Thu, 28 Apr 2011 14:07:40 -0700 (PDT)
Received: from chello080108243032.15.14.vie.surfer.at (chello080108243032.15.14.vie.surfer.at [80.108.243.32])
        by mx.google.com with ESMTPS id u15sm1243743bkf.4.2011.04.28.14.07.39
        (version=TLSv1/SSLv3 cipher=OTHER);
        Thu, 28 Apr 2011 14:07:39 -0700 (PDT)
Cc: caml-list@inria.fr
Message-Id: <2E33DAF4-C496-41ED-9208-61E66BD1AB82@gmail.com>
From: Vincent Aravantinos <vincent.aravantinos@gmail.com>
To: Ethan Burns <burns.ethan@gmail.com>
In-Reply-To: <BANLkTi=55g=rwiRm03_eS=uyGGDCoi4ezg@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes
Mime-Version: 1.0 (Apple Message framework v936)
Date: Thu, 28 Apr 2011 23:07:38 +0200
References: <BANLkTi=55g=rwiRm03_eS=uyGGDCoi4ezg@mail.gmail.com>
X-Mailer: Apple Mail (2.936)
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by walapai.inria.fr id p3SL7khb022589
Subject: Re: [Caml-list] Comparing variant types

Hi,

without entering any details, probably the following links would be  
interesting to you:

http://ocaml.janestreet.com/?q=node/33
http://ocaml.janestreet.com/?q=node/35

V.

Le 28 avr. 11 à 21:16, Ethan Burns a écrit :

> Hi,
>
> I have a program that uses variant types as an enumeration.  While
> profiling, I noticed that compare_val was being called a bunch.  When
> I went to inspect why this was the case, it turns out that it was
> being called to compare equality of my variants.  I am a bit confused,
> however, because my understanding was that variants that are declared
> without an 'of' clause were just represented as integers and therefore
> a type containing only these simple elements should be directly
> comparable (no compare_val).
>
> While looking further into this, I found a little example where the
> compiler seems to produce a simple comparison in one case and not in
> another:
>
> type dir = Left | Right | Up | Down | No_op
>
> (* performs a simple comparison *)
> let f a = a <> Right
>
> (* calls out to C to do compare_val *)
> let g (a:dir) b = a <> b
>
> There is the -dlambda output:
>
> (seq
>  (let (f/69 (function a/70 (!= a/70 1a)))
>    (setfield_imm 0 (global Test!) f/69))
>  (let (g/71 (function a/72 b/73 (caml_notequal a/72 b/73)))
>    (setfield_imm 1 (global Test!) g/71))
>  0a)
>
> Since both functions know that the types of the elements being compare
> is 'dir', which contains only simple elements, why does the g function
> still use compare_val?  Does the compiler not perform this particular
> optimization?
>
>
> Best,
> Ethan
>
> -- 
> Caml-list mailing list.  Subscription management and archives:
> https://sympa-roc.inria.fr/wws/info/caml-list
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs
>