Re: [Caml-list] Comparing variant types

[Dmitry Bely <dmitry.bely@gmail.com>]

On Thu, Apr 28, 2011 at 11:16 PM, Ethan Burns <burns.ethan@gmail.com> wrote:
> 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?

I don't know why structured compare is not optimized, but physical one
(which does the same in your case) is optimized away as expected.

let g (a:dir) b = a != b

- Dmitry Bely