Constant-Function

[ELIOT@cs.umass.edu]

   From:	IN%"edsel!jonl@labrea.stanford.EDU"  "Jon L White" 11-MAY-1988 00:58
   
   re: I think there should be some way to closely associate global 
       declaration-type stuff with a function's definition.   . . . Of course, 
       the world will not come to an end because people have to use a separate
       proclaim.  I just think it would be nicer to put everything
       about a function definition into a single form.
   
   This is a very good point.  Perhaps the bottleneck is that CL can't
   agree to semantics for *any* declaration (except for SPECIAL); some
   compiler's basically throw all declarations away (except for SPECIAL).
   
   
   re: Another solution is to define a macro encapsulaing the DEFUN and
       PROCLAIM. . . .  I also don't have a good name for such a macro.  
       'Defconfun' is rather bletcherous.  'define' would do, but Sussman's 
       students would start schemeing against me.
   
   Part of the problem I've been having with the "constant function" declaration
   is it's vagueness.

Its perfectly clear to me :-)

   In your original message you characterized it as "won't 
   redefine the function at runtime";

Meaning that the definition available at compile time will be the same
as the definition in force when the function call is executed.
The principle, but not exhaustive, consequences of this are that
the compiler can depend upon the FTYPE being fixed, and it is
permitted (but not required or even requested) to open code
the function call.

   but as subsequent dialogue shows, there is
   very little feeling that that implies anything worthwhile beyond what the 
   existing declarations (like ftype, speed/safety etc) provide.  "Never 
   redefine, at all, ever" is just too stringent to be useful.

It "is an error" to change the definition of a function that has
been declared to be a 'constant-function' unless you recompile/reload
all calls to that function that have been compiled while that declaration
was in force.  At best you may not get the new behavior.  At worst you
might execute code with sufficiently invalid assumptions that the lisp
will crash.
   
   Further, my assumption that "Never redefine"  characterizes the meaning
   you intended seems to have caused confusion, as evidenced by replies by 
   others; in particular, some (perhaps yourself?) are primarily concerned 
   with the stability of the argument spectrum, so that a compiler *might* 
   be licensed to use a different function-to-function protocol.  Maybe I'm 
   confused here too, in which case I'll just drop this line of reasoning; but 
   isn't argument spectra information is already specifiable via the ftype 
   declaration?

   I tried to suggest that maybe you wanted to cover the case that is currently
   not covered by any CL declaration -- that of "constant folding" (barmar
   called it "reducible";  but his example failed to fold the constant form --
   it only coalesced common subexpressions).  Such "constant folding" at compile
   time is a critical component of Lucid's optimizing compiler; but the data-
   base of what is "foldable" isn't user-accessible.  There is currently no CL 
   declaration that covers this case.  Accepting barmar's terminology, I see a 
   reasonable place for a REDUCIBLE declaration; would you?
   
I think that INLINE combined with algebraic simplification is equivalent
to constant folding.  What I object to is that 'inline' can cause bloating
if the simplifier isn't good enough.  It really is the phrase "it is
desirable to open-code" that bothers.  If that said "It is allowed to
open-code..." and "the compiler should make a reasonable heuristic
decision based upon the amount of object code that is likely to
be produced."  I want to tell the compiler what is legal and have it
do the right thing.  That isn't my reading of the current definition
of 'inline'.

Consider (again) this code:

  (defun fix-base-system (pkg)
     (do-all-external-symbols (sym pkg)
       (when (fboundp sym)
         (proclaim (list 'constant-function sym))))))

   (fix-base-system 'lisp)
   (fix-base-system 'kee)
   (fix-base-system 'umass-utilities)

This tells the compiler that I am not going to redefine "CONS" and "CAR"
and "CDR" and the other 500 functions.  The compiler can do constant
folding and open coding or whatever is valid and appropriate for
calls to those functions.  But I want the compiler to assume that
my functions are full of bugs (too true, too often) and calls to 
those functions should be tracable/redefineable/debugable.

Is there some combination of FTYPE/INLINE that provides a portable
substitute for the above?  It must not cause code-bloating in any
legitimate interpretation of the Common Lisp standard, and should
not require typing 500 declarations.  Furthermore, it should not
cause conflicts because of upwards compatible extensions to
Common Lisp functions (such as extra keyword args).