[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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 --