Re: [Caml-list] Bug? Printf, %X and negative numbers

[Ville-Pertti Keinonen <will@exomi.com>]

> 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