>You are missing the point. It is not true that building a program requires
>full recompilation. The point that Prof. Hickey made was that a program
>requires full recompilation if you make a change then build *native* code.

Actually, this kind of misses the point I was making (perhaps 
poorly).  There are some programs that have a minimum performance floor 
below which they fail to function correctly because they have a "real time" 
user feedback loop.  Games are one example.  You can't actually do useful 
work on a game without being able to run it at reasonably interactive 
framerates because of this feedback loop.  It gets worse, because you have 
another layer of algorithms that attempt to compensate for framerate 
variances, and so you're not even running the same code at low framerates, 
often times.  So, I can't use the bytecode compiler for development and 
haven't been able to for most of the lifetime of my project.  (See posts 
from over a year ago wishing I could link bytecode and native code modules 
together for this feedback reason.)

It may be that the intersection of these two characteristics ("large scale 
projects" and "realtime feedback requiring native compilation") is not an 
interesting set for the caml team to target, although I would argue it's an 
important target to support if a language is to be considered "general 
purpose" and compete with C++.  Unfortunately, this rules out a lot of 
games, which is my area, and one of the places where caml could have a 
chance at success because the project-based nature of the industry means 
there are clear frequent opportunities to make a big language switch 
(unlike industries that evolve code for decades).  This is why I am 
evaluating caml for games by writing my current game in it.  I just wish I 
would have known this "bug" existed before starting because it might have 
changed my mind.  Is this documented somewhere that I overlooked?

>In my experience, it isn't as bad as you make it sound like.  Touching
>early modules doesn't cause a recompile of everything, only modules that
>directly depend on it.  The inlining seems to only happen to one level.

I don't think this is true, since the recompile of the parent will mean the 
recompile of its parents, won't it (it does in my tests)?  And, even if it 
was true, it's still not great, because you really want to be able to edit 
algorithms in math3d.ml without recompiling the whole game.

Chris


-------------------
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