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 SAA14361; Fri, 4 Apr 2003 18:12:22 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id SAA13445 for ; Fri, 4 Apr 2003 18:12:20 +0200 (MET DST) Received: from epexch01.qlogic.org ([63.170.40.3]) by concorde.inria.fr (8.11.1/8.11.1) with ESMTP id h34GCJ525962 for ; Fri, 4 Apr 2003 18:12:19 +0200 (MET DST) Received: from epmailtmp.qlogic.org ([10.20.33.254]) by epexch01.qlogic.org with Microsoft SMTPSVC(5.0.2195.5329); Fri, 4 Apr 2003 10:12:43 -0600 Received: from [10.20.33.146] ([10.20.33.146]) by epmailtmp.qlogic.org with Microsoft SMTPSVC(5.0.2195.4905); Fri, 4 Apr 2003 10:12:43 -0600 Date: Fri, 4 Apr 2003 10:14:55 -0600 (CST) From: Brian Hurt X-X-Sender: Reply-To: Brian Hurt To: Ville-Pertti Keinonen cc: Gregory Morrisett , Subject: Re: [Caml-list] Bug? Printf, %X and negative numbers In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-OriginalArrivalTime: 04 Apr 2003 16:12:43.0558 (UTC) FILETIME=[05FA3460:01C2FAC5] X-Spam: no; 0.00; qlogic:01 caml-list:01 bug:01 printf:01 flu:99 mlton:01 -like:01 doable:01 bloat:01 foo:01 char:01 struct:01 locality:01 avoided:01 zillion:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk Sorry for being quiet for a couple of days- came down with the flu. I'm catching up on my email, so pardon the jumping into the middle of discussions. On Thu, 3 Apr 2003, Ville-Pertti Keinonen wrote: > > This is what I was suggesting. With its whole-program analysis, this > is obviously more straightforward for MLton, but I think it's also > feasible for more practical compilers (without ending up with C++-like > compile times). > I hadn't thought about polymorphism when I made my example. And thinking about it, while it still might be doable, it becomes way more ugly. One of the things I dislike about C++ template is code bloat. This is the undiscussed cost of templates. So you make a template foo. You create a foo and the compiler has to spit out a specialized instance of foo to deal with ints. Do foo and now you have two foos. Then you do foo, foo, foo, foo, foo, foo, etc. And this is assuming that the compiler is smart enough to notice that foo and foo can generally use the same specialization. And it takes heroic efforts to figure out that foo and foo might be able to use the same specialization. Maybe. So now you a dozen different specializations of foo<>. All almost identical. Say bye bye to any code locality. And this isn't even mentioning badly designed templates, like the one I found (no kidding!) for an array template that took it's length as a parameter. The compiler had to produce different specializations of the code for arrays length 3 and arrays length 4. Or some early C++ compilers which didn't have a way to say "this specialization is produced somewhere else", so if you used foo in 100 different files, you got 100 copies of the specialization of foo onto ints. This experience has made me violently opposed to specialization of code if it can be at all avoided. I'll take the performance hit to avoid having uppity zillion almost-identical copies of my code kicking around.\ And this applies to Ocaml even more so. I mean, consider the function: let f x = ... OK, so to specialize it for unboxed ints vr.s pointers takes two implementations of the function, f_pointer and f_int, right? So now consider the function: let f x y z w = ... Do we need 16 different specializations for this function? No. I'll take 31-bit ints any day. Brian ------------------- 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