[Haskell-cafe] Re: Compiler backend question

[Peter Verswyvelen]

Jon Harrop wrote:
> On Monday 07 January 2008 20:27:17 Peter Verswyvelen wrote:
>   
>> If your compiler (pretty amazing job btw) does whole program optimization,
>> can it remove the dictionary (aka v-table in C/C++ parlance?) overhead of
>> type classes? Because if I understand it correctly, unless one uses
>> existential types, a dictionary can be compiled away since the type in
>> question is known at compile time?
>>     
>
> Yes. This is essentially what F# does.
>   
Hang on.

When I asked a similar question in the F# forum, it seemed that F# 
simply does not have type classes (but it does support .NET interfaces), 
and root functions are only fully polymorphic when you mark them *inline*.

For example, the following will not work in the current version of F#:

**let add x y = x + y
let t1 = add 1 2
let t2 = add 1.0 2.0**

The first usage of add forces it to work on integers, and then its type 
is settled once and for all. If I understood it correctly, this is 
because the "root polymorphic" add function can only work on specific 
types because it gets compiled into an object file.

You can force it to work on any type on which + can be applied by 
forcing the function to be inline, like

let inline add x y = x+y
let t1 = add 1 2
let t2 = add 1.0 2.0

Then I guess the code will not be part of the object file, but it will 
be inserted inplace whenever it gets used (which could result in code 
bloat?)

Can the same trick be used in GHC?

Regarding Derek Elkins excellent example

f :: Show a => Int -> a -> String -- type signature required
f 0 x = show x
f n x = f (n-1) (x,x)

this indeed cannot be inlined nor optimized away, since you generally 
don't know the value of the first parameter at runtime. But this is a 
very specific case no? According to what I interpret from John Meacham's 
email, this case is an exception, and in many cases class type 
dictionary overhead gets compiled away?

Thanks,
Peter