George Russell wrote:
>
> (3) Simon Peyton Jones' comments about dictionary passing are a red herring,
> since they assume a particular form of compiler. Various (MLj, MLton)
> ML compilers already inline out all polymorphism. Some C++ compilers/linkers
> do it in a rather crude way as well, for templates. If you can do it,
> you can forget about dictionary passing.
[Standard disclaimer: I write prototype code that's never `finished' to
ever-changing specs in a university environment; other people probably
view things differently.]
I'm not sure I'd agree about this. Note that there's two levels, inlining
polymorphic functions at the call site and `instantiating polymorphic
functions at each usage type' without doing the inlining. C++ compilers
have to at least do the second because of the prevailing philosophy of
what templates are (i.e., that they're safer function-macros). Some of the
time this is what's wanted, but sometimes it imposes annoying compilation
issues (the source code of the polymorphic function has to be available
everytime you want to use the function on a new class, even if its not
time critical, which isn't the case for Haskell). I also often
write/generate very large polymorphic functions that in an ideal world
(where compilers are can do _serious, serious_ magic) I'd prefer to work
using something similar to a dictionary passing implementation. I'd argue
that keeping flexibility about polymorphic function implementation (which
assumes some default but can be overridden by the programmer) in Haskell
compilers is a Good Thing.
Given that, unless computing hardware really revolutionises, the
`speed/memory' profile of todays desktop PC is going to recurr in wearable
computers/PDAs/etc I believe that in 20 years time we'll still be figuring
out the same trade-offs, and so need to keep flexibility.
___cheers,_dave________________________________________________________
www.cs.bris.ac.uk/~tweed/pi.htm|tweed's law: however many computers
email: [EMAIL PROTECTED] | you have, half your time is spent
work tel: (0117) 954-5250 | waiting for compilations to finish.
_______________________________________________
Haskell-Cafe mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell-cafe
