BLOCK construct actually turns out to be a MacLISP PROGN. (The routine
LAMBDACATE in the Appendix is responsible for this analysis.)
{Note Evaluation for Effect}
Another case of interest is a combination whose function position
contains a variable with a KNOWN-FUNCTION property. The value of this property
is the node for the CPS version of the function, which provides information about
pox ' in code generation strategies. We can decide which arguments needn't be
passed as for the ((LAMBDA ...) ...) case, and can also arrange to call the
function with a direct (MacLISP) GO to the appropriate tag within the module.
The set-up of the environment depends on whether the function is non-closed or
partially closed; in the latter case the partial closure is the environment, and
in the former the environment can be recovered from the current one (and may even
be the same).
A certain amount of "peephole optimization" [McKeeman] is also performed,
primarily to make it easier for people to inspect the code produced, since the
MacLISP compiler will handle them anyway. Examples of these are avoiding the
generation of SETQ of a variable to the value of that same variable; reduction
of car-cdr chains to single functions, such as (CAR (CDR (CDR x))) to (CADDR x);
removal of nested PROGN's such as
(PROGN a (PROGN b c) d) => (PROGN a b c d)
and the like; and simplification of nested COND's, such as
(COND (a b) (COND (a b)
(T (COND (c d) => (c d)
...))) ...)
One of the effects of this last peephole optimization is that many times, when
the user writes a COND in a piece of SCHEME code, that COND is expanded into IF
