Version française
Home     About     Download     Resources     Contact us    
Browse thread
RE: [Caml-list] Bug? Printf, %X and negative numbers
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Gregory Morrisett <jgm@C...>
Subject: RE: [Caml-list] Bug? Printf, %X and negative numbers
>For generic code, it obviously requires either boxing or specialized 
>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 
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.  

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.  

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.

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.

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.  

-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