Constant-Function

[SOLEY@XX.LCS.MIT.EDU]

    Date: Tuesday, 10 May 1988  22:20-EDT
    From: Jon L White <edsel!jonl at labrea.stanford.edu>
    To:   ELIOT at cs.umass.edu
    cc:   common-lisp at sail.stanford.edu
    Re:   Constant-Function

    re: Knowing the FTYPE of sqrt does not allow a compiler to substitute 2.23 for
        (sqrt 5).  You might redefine SQRT as SIN without violating the FTYPE.

    Right.  So your intention for "constant function" really was more along the
    line of "constant foldable" (or "reducible"), just as I guessed in my first 
    message?

I think there are *three* kinds of compiler optimizations we're
talking about, not the two that have been bandied about.  Given the function

	(defun bar (x) (+ x 1))

the form (foo (bar 7) (bar 7)) might be compiled in several ways:

* INLINE compilation would be (foo (+ 7 1) (+ 7 1)).  Yes, a later
  constant folding stage would do more.  But *this* is what INLINE means.

* CONSTANT FOLDING, as JonL point out, would be (foo 8 8).  Note that
  in the general case this potentially requires executing random user
  function definitions from within the compiler.

* But REDUCIBLE is what Barmar said; avoid re-executing the function
  at run time if the arguments are the same (yes, this is the same as
  common subexp elim).  In other words, a source-to-source transform
  might yield (let ((gensym (bar 7))) (foo gensym gensym)).  Note that
  this does *not* require executing user code.  I'm sure that this is
  what Multics PL/1 does (though my old 1976 Multics PL/I manual
  doesn't mention it).

These transforms obviously have different effects on code size and
runtime behavior (particularly in a non-functional language).

I agree with the comment that we need to provide the compiler with
information about *the function* rather than how we think the compiler
should *treat* the function at compile time.

	-- Richard Soley