Browse thread
[Caml-list] Stupid question
[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
| Date: | -- (:) |
| From: | Jacques Garrigue <garrigue@k...> |
| Subject: | Re: [Caml-list] Stupid question |
From: skaller <skaller@tpg.com.au> > On Thu, 2004-01-15 at 11:03, Brian Hurt wrote: > > 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... Jacques Garrigue ------------------- 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