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 _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
