> Note that for well-known procedures, all variables that are free in the lambda are also free in the caller I don't think this is right, unless given an unnec

> Note that for well-known procedures, all variables that are free in the lambda are also free in the caller I don't think this is right, unless given an unnecessarily strict definition of `well-known`. A contrived counterexample: let example x y = let f = let z = big_calculation x in (fun t -> if t then z else 0) in (fun q -> f q + f y) 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. Optimising this example effectively is a bit tricky - the 'standard' 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 -> ...). A more aggressive method would be to discover that all references to f are within (fun q -> ...) and inline the free variables of f into its closure, avoiding an indirection. It's quite a fun subject - there are various implementation tricks for curried functions and partial application too, which aren't very important in Scheme but are crucial for ML.