SIDE-EFFECT-FREE/STATELESS Functions

[Jon L White <edsel!jonl@labrea.stanford.edu>]

re: . . . When defining a function
    named bar, one declares properties of that function and all future
    redefinitions of the function [name] by putting a declare inside the 
    function's definition.  When calling a function named bar, the 
    declarations attached to the definition that will be called are used.

(I inserted the bracketed "[name]" in your comments quoted above, to be 
consistent with your emmendations of your previous message.)

The issue is that the Symbolics' declaration can't be a proclamation because 
it doesn't apply specifically to a name for the function.  It does seem a 
bit of a departure from CLtL to acquire global compilation directions out 
of the current binding of a function name rather than using PROCLAIM.  

I see a reasonable amount of code that calls SETF on symbol-function; how 
would the symbolics style declaration handle this? the same as if it had 
been a DEFUN?  Perhaps what is needed is something beyond DEFUN that, like 
DEFVAR, will do implicit proclaims on the name as well as setting initial 
values;  (SETF SYMBOL-FUNCTION) would remain "primitive", like SETQ.

re: I don't think I should admit to knowing what you mean by implementation
    dependent concepts like "binding" and "cell".  . . . 

The term "binding" to mean an assignment of value to an identifier, whether
temporary or permanent, has been around the Lisp world for decades.  I don't
even think it is Lisp-world specific.  Also, cells aren't especially 
"implementation-dependent concepts" -- see the current discussion on the 
Scheme mailing list about "CELLS" (especially re ML).  Even beyond that 
theoretical scope, there is a common practice in the Lisp comunity to speak 
of setting a dynamic variable's value as "setting it's value cell"; rarely, 
if ever, is there any point to making a distinction between the two, 
regardless of how an implementation handles dynamic variables.


One interesting avenue for maintaining consistency between proclamations and
"reality" is to signal errors whenever the compiler can determine that a 
proclamation is being violated.  So an attempt to proclaim RANDOM "simple" 
would generate an error; and a subsequent "non-simple" definition of FOO, 
where FOO had been proclaimed "simple", should signal an error or warning.
Of course, not every compiler and/or interpreter is capable of enough 
analysis to distinguish "simple" from "non-simple" from "unknown"; this is 
in the realm of "user-friendly" rather than language semantics.



-- JonL --