Compiler Optimizations are Awesome
I&#x27;m posting this as a top-level comment, but it&#x27;s really a reply to the discussion downthread about compilers being able to work magic if we let them. Better still, why not help them?<p>Something I took for granted for the longest time about Haskell (which remains the only language I know of with the feature) is the ability to write user-defined &quot;rewrite rules&quot;. You can say, &quot;okay, GHC, I know for a fact that if I use these functions in such-and-such way, you can replace it  by <i>this</i> instead&quot;.<p><pre><code>  {-# RULES 
    foo x (bar x) =  
    superOptimizedFooBar x 
   #-}
</code></pre>
A rule like this would be based on the programmer&#x27;s knowledge of FooBar theory, which tells her that such an equality holds. The compiler hasn&#x27;t studied lax monoidal FooBaroids and cannot be expected to infer this on its own. :)<p>Now, anywhere a user of this code writes something like<p><pre><code>  foo [1,2,3] (bar [1,2,3])
</code></pre>
the compiler will substitute<p><pre><code>  superOptimizedFooBar [1,2,3]
</code></pre>
in its place. This is a nice way to bring the compiler &quot;closer&quot; to the programmer, and allow the library author to integrate domain-specific knowledge into the compiler&#x27;s optimizations.<p>You can also &quot;specialize&quot; by using faster implementations in certain cases. For example,<p><pre><code>  timesFour :: Num a =&gt; a -&gt; a
  timesFour = a + a + a + a

  timesFourInt :: Int -&gt; Int
  timesFourInt x 
    = rightShift x 2

  {-# RULES
      timesFour :: Int -&gt; Int
    = timesFourInt
   #-}
</code></pre>
If you call timesFour on a double, it will use addition (ha!) but using it on an Int uses bitshifting instead because this rule fires.<p>High-performance Haskell libraries like vector, bytestring, text, pipes, or conduit <i>capitalize</i> on this feature, among other techniques. When compiling code written using libraries like this, this is how it goes:<p>- rule #1 fires somewhere
 - it rewrites the code into something that matches rule #2, &quot;clearing the way&quot; for it to fire
 - rule #2 fires
 - rule #3 fires
 - rule #1 fires again
 - rule #4 fires<p>and so on, triggering a &quot;cascade&quot; of optimizations.<p>The promise of Haskell is that we already have a &quot;sufficiently smart compiler&quot;: <i>today</i>, with good libraries, GHC is capable of turning clear, high-level, reusable functional code with chains of function compositions and folds and so on into tight, fast loops.<p>--<p>I must add, though, that getting rewrite rules to fire in cascades to get &quot;mad gainz&quot; requires one to grok how the GHC inliner&#x2F;specializer works.<p><a href="http:&#x2F;&#x2F;mpickering.github.io&#x2F;posts&#x2F;2017-03-20-inlining-and-specialisation.html" rel="nofollow">http:&#x2F;&#x2F;mpickering.github.io&#x2F;posts&#x2F;2017-03-20-inlining-and-sp...</a><p>Data.Vector also utilizes an internal representation that makes fusion explicit and hence predictable (inevitable, even) called a &quot;bundle&quot;:<p><a href="https:&#x2F;&#x2F;www.stackage.org&#x2F;haddock&#x2F;lts-8.16&#x2F;vector-0.11.0.0&#x2F;Data-Vector-Fusion-Bundle.html" rel="nofollow">https:&#x2F;&#x2F;www.stackage.org&#x2F;haddock&#x2F;lts-8.16&#x2F;vector-0.11.0.0&#x2F;Da...</a><p>but this relies on rewrite rules too, e.g. the previous module contains this rule:<p><pre><code>  {-# RULES

  &quot;zipWithM xs xs [Vector.Stream]&quot; forall f xs.
    zipWithM f xs xs = mapM (\x -&gt; f x x) xs   #-}</code></pre>