Static data and RULES

[David Feuer]

On Friday, February 17, 2017 12:33:12 AM EST Simon Peyton Jones via ghc-devs 
wrote:
> The "L" rule becomes problematic when we try to identify static data the
> simplifier shouldn't have to try to optimize. If it identifies LCon 0 as
> static, the "L" rule will never fire.
 
> Why doesn’t it fire?
> 
> I’m afraid I still do not understand what change is proposed, so I’m finding
> it difficult to see how to fix problems with it.

I'm sorry; I wasn't trying to be obtuse; easy to drop context by mistake. The 
idea, at least roughly, is to have a "static" flag on each term. A term is 
considered static if it's

1. A Core literal,
2. A nullary constructor, or
3. A constructor whose arguments are all static.

Once a term is flagged static, the simplifier simply shouldn't try to optimize 
it--doing so is simply a waste of time.

The trouble is that rules like "L" can turn things that *look* utterly static 
into other things, through simplification that we then actually need! So we 
need to either try to figure out what's *really* static (which is complicated 
by orphan RULES) or we need to let users say so. I jumped for phased INLINE 
and NOINLINE pragmas because users are already accustomed to using those to 
say "I'm going to match on this with rules". It struck me also as a good way 
also to deal with the "S" rule that you've apparently found some other way 
around.

David