Big INLINE patch

[Simon Marlow]

> I'm about to commit the long-promised inline patch. The nofib results are
> attached, relative to the current HEAD.
> 
> * Execution times seems to improve quite a bit,
>   but I don't know whether to trust them.
> 
> * Allocations are generally down slightly. One outlier is 'rewrite'
>   which has a very delicate CSE opportunity, so I don't mind this.
>   I'm still chasing 'bspt', but I don't think it's a big deal.
> 
> * Binary sizes wobble about a bit, and are up 0.9% on average,
>   but I think that's acceptable.
> 
> * Compile times seems down fairly consistently
> 
> * Module sizes wobble about a bit; average is down 0.5%
> 
> The main goal is to get a new, more robust framework for programs that use
> a lot of overloading, which NDP does.  For NDP, the new stuff makes GHC
> usable, whereas it's just hopelessly slow and/or all bloated code without
> it.  I'm quite keen to the patch in, because at the moment I have to send
> a weekly patch to Australia, and it's becoming difficult at their end.
> 
> There a *LOT* of changes to many files, so committing this patch will make
> it more difficult to move stuff to the branch.
> 
> Happy for me to go ahead?

I support this.  I'd like to see any uncommected parts of the patch split off into separate commits (e.g. comment-only changes) if that's at all possible, though.

If you use darcsum (http://chneukirchen.org/repos/darcsum/darcsum.el) recording lots of little patches is a breeze.

Cheers,
	Simon