| I think I also found a typo: Quite right, thanks -- now fixed. | Recently I found that specialisation interacts in an unexpected way with | explicit RULES (and with inlining). I used a function multiple times and | this seemed to make GHC specialising this function (although I did not | used a SPECIALISE pragma) to the particular type. But then this function | was no longer available for fusion. Yes, specialisation generates new RULES. These new rules apply all the time, so they may rewrite your call to f before your fusion rules run. This is a bad thing. Really, specialisation should generate rules for a particular phase 'spec', and you should be able to add your fusion rules to precede or follow 'spec'. | Also in one case declaring a function 'foo' as INLINE [0] avoided fusion | of 'foo', where NOINLINE [0] did the fusion in phase 2. I assumed that | these two pragmas are identical in phases before 0. I'm not sure what is going on here | Summarized I think it is not only required to have better control over the | phases of the optimizer but to have a clear unifying concept of several | kinds of program transformations, namely SPECIALISE, INLINE, RULES. I can hardly argue with a "clear unifying concept". But I'm not quite sure what you mean. Here's a stab. You could put this on the wiki and refine it with help from this end. * SPECIALISE generates a rule * RULES specifies a rule * INLINE is just like a rule (lhs = rhs) The latter two can be controlled to some extend by the "phase" mechanism. The first should be. Did you mean more than that? Simon