| I would have imagined an optimisation step that only activates when a | constructor is passed into a function to see if it produces a branch that | can be precomputed, and then tries to determine if it is worth making a | specialized function with that case eliminated. Or possibly having each | function inspected to see if it has branches that could be eliminated if a | constructor was passed as an argument. That's precisely what GHC does. My explanation before was too brief, sorry. The algorithm is described in "Secrets of the GHC inliner" http://research.microsoft.com/%7Esimonpj/Papers/inlining/index.htm But it still only makes a specialised copy if the function is "small enough". Obviously a great big function with a tiny specialisation opportunity would be a poor candidate. | I must say I'm extremely disappointed with this. I believe I was taught | in my undergraduate CS program (but perhaps I wasn't) that one ought not | to make these sorts of trivial hand optimisations, because compilers are | smart enough to figure out these sorts of things by themselves, and they | know more about that target platform that you do. In particular the | propaganda about side-effect-free functional languages was a promise that | they would use the strong types and side-effect-freeness to do all sorts | of wonderful optimisations. Well I think if you use -ddump-simpl you'll see a program that often looks pretty different to the one you wrote. I often have difficulty figuring out just how GHC managed to transform the source program into the optimised one. Of course it's far from perfect! Fortunately, GHC is an open-source compiler, so the way lies open for anyone, including you, to improve the inlining decisions. I'm sure there are good opportunities there. Simon PS: you mention "knowing about the target platform". That's one thing that GHC is distinctly poor on. It leaves all target-platform-specific optimisations to the C compiler.