Function inlining in closLang

[myreen]

Currently, all function inlining happens in BVL. However, there are certain functions that would need to be inlined before closures are compiled. In particular functions that take functions as arguments, such as opt_map below.

fun opt_map f opt = 
  case opt of 
    NONE => NONE
  | SOME x => SOME (f x);

Example: for the call to foo in opt_map foo x to be optimised, the definition of opt_map needs to be expanded.

I suggest this optimisation is implemented by reusing clos_number and clos_known. These should be run first, then any small function should have its definition inserted into the known-annotated application. A few minor passes might then be needed in the same way as bvl_inline currently combines several passes to clean up the raw inline result.

Note that inlining destroys one of the important properties of clos_number (namely that every closure creation has a unique number), so clos_number and clos_known would need to be run again to reset the numbering and redo the known annotations.

If this optimisation is done well, then it might make bvl_inline obsolete.

[myreen]

We can probably avoid rerunning clos_number and clos_known if we are happy to use a slightly weaker property: closures are allowed to have the same closure number if their bodies are identical. It would be neat if we could avoid rerunning the clos_number and clos_known passes after inlining.