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

[Brian Hurt <brian.hurt@qlogic.com>]

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<type>.  You 
create a foo<int> and the compiler has to spit out a specialized instance 
of foo to deal with ints.  Do foo<long> and now you have two foos.  Then 
you do foo<char>, foo<short>, foo<float>, foo<double>, foo<struct this>, 
foo<struct that>, etc.  And this is assuming that the compiler is smart 
enough to notice that foo<unsigned long> and foo<size_t> can generally use 
the same specialization.  And it takes heroic efforts to figure out that 
foo<int> and foo<unsigned int> 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<int> 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