&gt; Note that for well-known procedures, all variables that are free in the lambda are also free in the caller<p>I don&#x27;t think this is right, unless given an unnecessarily strict definition of `well-known`. A contrived counterexample:<p><pre><code>    let example x y =
      let f =
        let z = big_calculation x in
        (fun t -&gt; if t then z else 0) in
      (fun q -&gt; f q + f y)
</code></pre>
Here f is bound to a known function, which is only called and never escapes. All of the known-function optimisations should apply. However the variable z is not in scope at the call sites of f.<p>Optimising this example effectively is a bit tricky - the &#x27;standard&#x27; thing to do is construct a closure that contains z (but need not contain a code pointer, since all call sites are known), which is itself contained within the closure for (fun q -&gt; ...). A more aggressive method would be to discover that all references to f are within (fun q -&gt; ...) and inline the free variables of f into its closure, avoiding an indirection.<p>It&#x27;s quite a fun subject - there are various implementation tricks for curried functions and partial application too, which aren&#x27;t very important in Scheme but are crucial for ML.