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 XAA12083; Wed, 2 Apr 2003 23:12:08 +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 XAA11329 for ; Wed, 2 Apr 2003 23:12:07 +0200 (MET DST) Received: from mail.exomi.com (mail.exomi.com [217.169.64.72]) by nez-perce.inria.fr (8.11.1/8.11.1) with ESMTP id h32LC6901528 for ; Wed, 2 Apr 2003 23:12:07 +0200 (MET DST) Received: from exomi.com (unknown [10.0.5.5]) by mail.exomi.com (Postfix) with ESMTP id 11BCE5D03; Thu, 3 Apr 2003 00:12:06 +0300 (EEST) Date: Thu, 3 Apr 2003 00:12:05 +0300 Subject: Re: [Caml-list] Bug? Printf, %X and negative numbers Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: To: "Gregory Morrisett" From: Ville-Pertti Keinonen In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) X-Spam: no; 0.00; caml-list:01 bug:01 printf:01 unboxing:01 floats:01 mlton:01 avoids:01 monomorphic:01 -like:01 implemented:01 passing:01 generic:01 generics:01 runtime:01 recursion:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk > While this approach is viable, it has a lot of costs. For > some of the tradeoffs, I suggest reading Xavier's excellent > paper in the 1998 Types in Compilation workshop. Do you mean the '97 paper (unboxing of floats in OCaml, among other things)? I had read that one. I just read the '98 paper, too, but it doesn't go into much detail. > MLTON avoids these issues by specializing polymorphic code at > all of its uses so that it becomes monomorphic (not unlike C++), > at the price of separate compilation. 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 was thinking about keeping separate compilation by either using specialization as an optimization when the number of variations is reasonable at the point where the polymorphic code is implemented, or passing the generic code in a semi-compiled form and letting it be specialized on (first) use. The latter is obviously better, but requires quite a bit of work on the intermediate compiled form and linking. > Generics in C# go yet another route with runtime specialization > which has distinct advantages like the possibility of supporting > polymorphic recursion (see Andrew Kennedy & co's papers.) > There are different tradeoffs here, due to features such as > reflection and "instanceof", etc. Thanks for the pointer. > In short, there's a wealth of literature on this subject. > Ocaml has taken a very expedient approach and in my opinion, > it would be difficult to produce an alternative that > achieves the same performance without introducing a lot > of complexity. I agree that the OCaml runtime makes good compromises that work well in practice. Any added complexity would probably hurt symbolic code, which seems to have had a high priority in considerations of tradeoffs. I don't feel strongly about the need for naked integers, so on my part this is just speculation and general curiosity. What I would like is specialization of functors. I hate using data structures that lose to Java in performance. ;-) ------------------- 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