So I'm trying to program the GHC term rewriting system again (ie the mighty simplifier) and it's not doing what I want it to do without me using unnecessarily large hammers. The crux is that I have a simple function that I want to be inlined early so that my other rules can match on the thing it expands into, however despite the {-# INLINE #-} pragma, it doesn't get inlined until a much later phase when it's too late for the rule to match. So currently I'm forced to use {-# RULES #-} to achieve the same effect, ie expanding the definition in an early phase. This feel like a hack of course. So either the INLINE heuristics could be tweaked to make these cases work or perhaps we should consider adding some other pragma for when we don't want to go by heuristics but are instead deliberately trying to do term rewriting. Anyway, here's the example. It's binary deserialisation. We have a couple important primitives: read :: Int -> (Ptr Word8 -> IO a) -> Get a and the applicative combinators (<$>) (<*>) for Get: fmapGet :: (a -> b) -> Get a -> Get b apGet :: Get (a -> b) -> Get a -> Get b So that we'll be able to match on these, we delay their inlining: {-# INLINE [0] apGet #-} {-# INLINE [0] fmapGet #-} {-# INLINE [0] read #-} The important rules linking these are: {-# RULES "fmap/read" forall f n a. f `fmapGet` read n a = ... "read/read" forall n m f x. read n f `apGet` read m x = ... #-} and finally we have: word8 :: Get Word8 word8 = read 1 peek {-# INLINE word8 #-} So when we write something like: foo :: Get (Word8,Word8,Word8) foo = (,,) <$> Get.word8 <*> Get.word8 <*> Get.word8 we want to expand word8 into it's definition in terms of read and then have the rules fire (which shares the bounds checks). Looking at the simplifier iterations we get to this step: ==================== Simplifier phase 2, iteration 1 out of 4 ==================== PutTest.foo :: Get.Get (GHC.Word.Word8, GHC.Word.Word8, GHC.Word.Word8) [Exported] [] PutTest.foo = Get.apGet @ GHC.Word.Word8 @ (GHC.Word.Word8, GHC.Word.Word8, GHC.Word.Word8) (Get.apGet @ GHC.Word.Word8 @ (GHC.Word.Word8 -> (GHC.Word.Word8, GHC.Word.Word8, GHC.Word.Word8)) (Get.fmapGet @ GHC.Word.Word8 @ (GHC.Word.Word8 -> GHC.Word.Word8 -> (GHC.Word.Word8, GHC.Word.Word8, GHC.Word.Word8)) (Data.Tuple.(,,) @ GHC.Word.Word8 @ GHC.Word.Word8 @ GHC.Word.Word8) Get.word8) Get.word8) Get.word8 Here is where we really must inline word8 or we're going to miss our opportunity once apGet and fmapGet get inlined. Sadly it doesn't inline it here (in phase 2), or in the next phase (in fact it does nothing in phase 1 at all). We get all the way to phase 0 and then go and inline everything (including word8). The behaviour is the same for 6.6 and 6.7.recentish (one month old). If we hit word8 with a bigger hammer: {-# RULES "inline word8" word8 = read 1 peekWord8 #-} then the whole thing works perfectly and we get really nice STG code at the end. I was under the impression that GHC considered a function more 'interesting' if it was mentioned in the LHS of a rule as is the case here. What is the right thing for me to do in this case? Just use the rule to do the inlining? The full source is here: http://haskell.org/~duncan/binary/ Get.hs and GetTest.hs (In the same dir is an example showing the opposite problem, GHC inlining a function when I asked explicitly for it not to. I reported that problem previously. Though I now realise I never filed a bug in trac for that one. I'll file bugs for both.) On the good news side, I'm getting excellent performance results for the serialisation and judging from the STG code for the deserialisation I expect it'll be great too. Duncan