English version
Accueil     Ŕ propos     Téléchargement     Ressources     Contactez-nous    

Ce site est rarement mis ŕ jour. Pour les informations les plus récentes, rendez-vous sur le nouveau site OCaml ŕ l'adresse ocaml.org.

Browse thread
[Caml-list] ocaml and large development projects
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2003-05-18 (06:10)
From: Chris Hecker <checker@d...>
Subject: Re: [Caml-list] ocaml and large development projects

> > Uh, isn't this a major flaw in the compiler?  Why does this happen?
>Inlining.  Inlining is an important optimization, especially for
>functional languages, where many functions are typically short.

Sure, but there has to be a better way to do this than forcing a recompile 
of the entire program when you change a debug print in your lowest level 
completely encapsulated library.  That's insanely bad software engineering, 
and this is a huge issue.  The only reason this hasn't been #1 on my list 
of "must fix"'s is because there's no way I would have even guessed this 
was the actual behavior...I didn't even bother to check this it's so 
absurd, I just assumed it worked and was some stupid makefile thing I was 
doing in my quick tests (since it works for bytecode).  Any production C++ 
programmer evaluating caml as a possible alternative for large scale 
software would simply laugh and write off the language as an option for 
this behavior alone, in my opinion.  Certainly all of the game developers I 
know would.

Do people think I'm overreacting there?  I can't believe anyone thinking 
about using ocaml for big native code projects wouldn't consider this a 
100% showstopper.  I certainly would have thought differently about using 
ocaml if I'd known this when I started my project.

>These dependencies are correctly displayed by ocamldep, though.

Well, that answers another confusion of mine when I did my quick tests a 
while back, but that certainly isn't an excuse for the behavior.  That's 
like saying "our programming language can't add two integers, but the 
compiler catches this and issues an error, so it's okay."

Don't people consider separate compilation and the ability to change 
implementation without complete project recompiles a fundamental 
requirement of non-toy languages?

If this can't be fixed, there needs to be a way to disable cross-file 
inlining so that it can be worked around (and the checksums should reflect 
this, and ocamldep should do the right thing, etc.), and then when you want 
to "globally optimize" you can recompile the world.

Totally flabbergasted,

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