skaller wrote:
> So what I believe Jon and Xavier mean here is that the
> Ocaml compilers compile code down to stuff which is easily
> predicted in terms of the input syntax. no magic like
> invariant code motion: What You See is What You Get.

I generally agree that automatic optimizations should not change
too much the behavior of programs unless they are very easy to
understand and predict; indeed we don't want to rely on subtle
properties of the code and see the performances degrade unexpectedly
when we change a tiny thing.

Having said that, I don't see how opposing a more effective inlining and
specialization strategy would let the programmers write better code.
Quite the contrary (manual inlining? come on...) in my opinion. These
optimizations are not so much about producing more efficient programs;
there're about letting the programmer write cleaner code. So maybe the
current Ocaml compiler expects good code as Jon says, but it forces us
to write not-so-good one :-/  A functional programmer has reasons to
become schizophrenic if he must ask himself questions such as "should I
make this piece of code a function or write it inline?" or "should I
restrict the type of this polymorphic function?" or "should I use
Array.iter or write a for loop?" all the time. MLton's strength is that
you don't have to pay the price for abstraction, i.e. cleaning up your
program (by factorizing it or making it more modular) does not degrade
performance. I have no experience with MLton, but I don't believe that
performances are much more difficult to predict than with OCaml (Stephen?).

  Alain