Unexpected lack of optimisation

[ajb at spamcop.net]

G'day all.

Quoting Simon Peyton-Jones <simonpj at microsoft.com>:

> Interesting thought.  I think you're describing a possible extension  
>  to the SpecConstr transformation described in "Call pattern   
> specialisation for Haskell"

Without reading the paper, that sounds right to me.

> Here 'x' is free in 'g', but x's value is known at g's call sites.    
> It's not enough just to know "x is a cons" inside g; we must also   
> have access to z,zs.

I would have thought that GHC already optimised this in a separate
pass.  Doesn't it do some kind of redundant case test elimination?

> And it's  arguably a bad shortcoming that currently the mere act of  
> lambda  lifting can affect how effective SpecConstr is.

Indeed.  It also suggests to me that perhaps lambda lifting the
pattern matching "retries" might _always_ be a good idea, given
that the programmer has no way of controlling inlining for this
kind of intermediately-generated function.

Cheers,
Andrew Bromage