Re: [Caml-list] Stupid question

["Nicolas Cannasse" <warplayer@free.fr>]

> > > I was poking around in the produced assembly code of some ocaml code
of
> > > mine, and I noticed something.  The construct:
> > > if (x < m) <> (y < m) then
> > > ...
> > >
> > > when the compiler knows that x, y, and m are all ints, it calls an
> > > external C routine to compare the two booleans.  But the construct:
> > >
> > > if (x < m) != (y < m) then
> > > ...
> > >
> > > does not.  Now, this isn't a big deal- I just replaced <> with != and
no
> > > problem.  But I was kind of interested in why the compiler didn't
catch
> > > and optimize this.  Is there some sort of subtle semantic difference
I'm
> > > too dense to see?
> >
> > Well, <> is a polymorphic value comparison.
> > Whereas != is a physical inequality comparison.
>
> Yes indeed.
> But the compiler is clever enough to use specific comparison functions
> when the type is known to be int or float.
> Since bool looks like a subset of int, one might expect it to be
> optimised also. However, bool is just a normal sum type, and since
> some sum types have non-constant constructors, in general sum types
> require a recursive comparison operation.
> For types where constructors are constant, this might be optimised...

You mean that actually comparisons on type t = A | B | C are using
polymorphic recursive C function ?
That's not nice, especially when working with lexers that generate this kind
of tokens. I would expect that such enumerations should be as fast as in C.
If someone hasn't posted yet a feature request for improving that, I'll do.

Nicolas Cannasse

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners