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 UAA07448; Wed, 2 Apr 2003 20:42:07 +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 UAA05947 for ; Wed, 2 Apr 2003 20:42:06 +0200 (MET DST) Received: from exchfe1.cs.cornell.edu (exchfe1.cs.cornell.edu [128.84.97.27]) by concorde.inria.fr (8.11.1/8.11.1) with ESMTP id h32Ig5505322 for ; Wed, 2 Apr 2003 20:42:05 +0200 (MET DST) Received: from EXCHVS2.cs.cornell.edu ([128.84.97.24]) by exchfe1.cs.cornell.edu with Microsoft SMTPSVC(5.0.2195.5329); Wed, 2 Apr 2003 13:42:01 -0500 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Subject: RE: [Caml-list] Bug? Printf, %X and negative numbers Date: Wed, 2 Apr 2003 13:42:00 -0500 Message-ID: Thread-Topic: [Caml-list] Bug? Printf, %X and negative numbers Thread-Index: AcL4+VRw2FcwQDN8TcG72+YCea08yQATJj+w From: "Gregory Morrisett" To: "Ville-Pertti Keinonen" , "Andreas Rossberg" Cc: X-OriginalArrivalTime: 02 Apr 2003 18:42:01.0251 (UTC) FILETIME=[8C5A2F30:01C2F947] X-Spam: no; 0.00; morrisett:01 cornell:01 caml-list:01 bug:01 printf:01 generic:01 boxing:01 mlton:01 untagged:01 passing:01 pointers:01 unboxed:01 doubles:01 thesis:01 avoids:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk >For generic code, it obviously requires either boxing or specialized=20 >versions of the code, as I suggested in a different message. The TIL (and TILT) and MLTON compilers support untagged integers. As you suggest (and Xavier well knows) the hard part is dealing with polymorphic code of which there is a lot in ML. Consider, for instance, a function such as map -- whether it produces integer cons-cells depends upon how map is instantiated. Life gets complicated when you don't have tags. TIL/T solved this by=20 passing type representations to polymorphic functions. These representations could be used to construct header words for objects to indicate which fields were[n't] pointers. The information was also used to support unboxed doubles, and a few other things. See my thesis for more information. =20 While this approach is viable, it has a lot of costs. For some of the tradeoffs, I suggest reading Xavier's excellent=20 paper in the 1998 Types in Compilation workshop. =20 MLTON avoids these issues by specializing polymorphic code at all of its uses so that it becomes monomorphic (not unlike C++),=20 at the price of separate compilation. 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.) =20 There are different tradeoffs here, due to features such as reflection and "instanceof", etc. In short, there's a wealth of literature on this subject. =20 Ocaml has taken a very expedient approach and in my opinion, it would be difficult to produce an alternative that=20 achieves the same performance without introducing a lot of complexity. =20 -Greg ------------------- 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