Call Arity, oneShot or both

[Simon Peyton Jones]

| The biggest loser is calendar, which uses scanl. I am not fully sure
| what went wrong here: Either the one-shot annotation on the lambda’s
| variable got lost somewhere in the pipeline, or despite it being there,
| the normal arity analysis did not use it.
| 
| But there is also a winner, fft2, with -1.5% allocations. Here Call
| Arity was not good enough, but oneShot did the jobs.

It's always useful to discover what happens.  Why didn't Call Arity do the job?  How did the one-shot-ness get lost?    I know it takes work to find out these things; but sometimes they show up something that is easy to fix, and which gives improvements across the board.

| best keep the oneShot annotation in the unfoldings: The isOneShotLambda
| flag is currently not stored in the interface. I work around this by
| making sure that the oneShot function is never inlined in unfoldings,
| but maybe it would be better to serialize the isOneShotLambda flag in
| interfaces, which might have other good effects?

Serialising the one-shot lambda info sounds like a good plan to me.
| If we want as much performance as possible, we should simply include
| both approaches. But there might be other things to consider... so not
| sure what the best thing to do is.

I'd be inclined to do both.  Call-arity hits programs where the programmer had no idea that there was something to do; or where the lambda isn't *statically* one-shot... it only becomes so when inlined into a particular context.   One-shot-lambdas may help in situations where the one-shot-ness is manifestly too hard to spot. 

Good work!  Keep a wiki page to describe the choices, point to the tickets, etc

Simon