Constant Functions

[Barry Margolin <barmar@Think.COM>]

    Date: Thu, 5 May 88 19:05:54 PDT
    From: Jon L White <edsel!jonl@labrea.stanford.edu>

    Isn't it the case that *any* proclaim about a function is equivalent to
    saying that that aspect of the function is "constant"?  What  you are 
    looking for is a way to say that "constant folding" is ok;  of course, 
    the function must be defined and usable in the compilation environment
    for this to work.  Generally speaking, "constant folding" is ok as long
    as the function is side-effect free; so maybe that is the declaration
    you want?

This isn't how I interpreted Eliot's CONSTANT-FUNCTION request.  In
Multics PL/I, we called the above "reducible".  If the compiler knows
that a function is reducible, then it can use common subexpression
elimination to optimize multiple calls, e.g. (+ (red-fun 10) (red-fun
10)) could be optimized to (* (red-fun 10) 2).

But that's not what Eliot was talking about.  His CONSTANT-FUNCTION
declaration promises that a function is not going to be redefined, so
the compiler may build in assumptions about things like the calling
sequence, the location of the code, etc.

It is the case that if the compiler does flow analysis and can determine
that a function is reducible on its own (for example, if a function
references no free variables and only calls reducible functions, it is
also reducible), then a CONSTANT-FUNCTION declaration would also allow
the compiler to make optimizations based on the reducibility.  If the
function happens to be reducible, but not declared CONSTANT-FUNCTION,
the compiler can't make the optimization because the function might be
redefined to a non-reducible function.

    re: The declaration (CONSTANT-FUNCTION foo) . . .  With SPACE=0, SPEED=3 this
	should be equivalent to an INLINE declaration.

I think "should" should be "could".  CL doesn't yet specify the precise
meaning of the various optimization levels, so it would be up to an
implementor to decide that this combination means that it should
inline-code all constant functions.

    I don't think so, or at least not if what you primarily want is a way to
    legitimze "constant folding".  For example,
       (defun run-around-and-double (x) 
	   ...lots of contorted code ...
	   ... ultimately returning (* 2 x) ...
	)

    Then declaring this a constant-function should permit the compiler to convert
    (run-around-and-double '6) into '12; but hopefully wouldn't cause in-lining
    of (run-around-and-double x).  I see 'inline' and 'constant-function' as
    independent dimensions.

I agree with Eliot's original statement.  However, your version follows
as a natural occurrence.  If the compiler is smart enough to determine
that RUN-AROUND-AND-DOUBLE does nothing but return its argument doubled,
then it should be able to determine this about the inline-substituted
code, too.  

    re: As a special case (declare constant-function) in a DEFUN is equivalent
	to both a proclaim and the defun.

    This is too special-casey.  Any declare in a DEFUN (or any other place that
    admits 'declare') should have only local, lexical scope; or at least, so I 
    think.

That's already not true of the VALUES declaration.  It specifies an
attribute of the function being defined, just as Eliot was suggesting
above.

                                                barmar