[Haskell-cafe] Re: (Chaos) [An interesting toy]

[Andrew Coppin]

> | In the latter case, we have resultant :: (Num n) => [n] -> n. I'm no
> | expert, but I would expect that this requires a method lookup on each
> | call, whereas with the more restrictive type I would expect the compiler
> | to be able to just link directly to the correct method implementation.
> | Am I mistaken?
>
> Probably not.  Remember that sum is *itself* overloaded, so if resultant calls sum there is not much it can do except pass on the appropriate dictionary to sum.
>
> Better would be to inline (and specialise) sum at this call site.  But at the moment GHC doesn't specialise functions defined in *other* modules.  That's another thing that could be improved (at the cost of risking constructing multiple copies of the same specialisation of 'sum'.
>   

Right. I see what you're saying.

Presumably changing it to resultant = foldl' (+) wouldn't help much either?


Seems to me there's always a tradeoff to be made between CPU time, RAM 
usage, and code size - if not other factors too. :-S But Haskell seems 
to be fairly unique in that (it looks like) it's possible to transform 
the code quite aggressively without too much difficulty. You wouldn't 
ever want to write source code for six different versions of sum, but if 
a compiler can do it automatically that's another matter. ;-)

I guess I was assuming that a function like sum is "simple enough" to 
get inlined at the call site - and hence possibly optimised at that 
site. Apparently not. By the way, is there some way of discovering what 
GHC has "really" done with your code, rather than what you "think" it's 
done? (Short of getting out a dissassembler that it...)