From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id IAA29674; Sun, 18 May 2003 08:10:45 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id IAA30659 for ; Sun, 18 May 2003 08:10:44 +0200 (MET DST) Received: from relay.pair.com (relay.pair.com [209.68.1.20]) by nez-perce.inria.fr (8.11.1/8.11.1) with SMTP id h4I6AhT07491 for ; Sun, 18 May 2003 08:10:43 +0200 (MET DST) Received: (qmail 12076 invoked from network); 18 May 2003 06:10:41 -0000 Received: from arda.pair.com (HELO compaqreview.d6.com) (209.68.1.133) by relay.pair.com with SMTP; 18 May 2003 06:10:41 -0000 X-pair-Authenticated: 209.68.1.133 Message-Id: <4.3.2.7.2.20030517225010.04b748a0@localhost> X-Sender: checker@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sat, 17 May 2003 23:10:03 -0700 To: David Brown From: Chris Hecker Subject: Re: [Caml-list] ocaml and large development projects Cc: "'caml-list@inria.fr'" In-Reply-To: <20030518054443.GA31538@opus.davidb.org> References: <4.3.2.7.2.20030517192812.033d9040@localhost> <4.3.2.7.2.20030517192812.033d9040@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam: no; 0.00; hecker:01 checker:01 caml-list:01 inlining:01 stupid:01 showstopper:01 dependencies:01 ocamldep:01 recompiles:01 checksums:01 compiler:01 chris:01 debug:01 ocaml:01 caml:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk > > 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, 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