[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- To: common-lisp@SAIL.STANFORD.EDU
- Subject: Constant-Function
- From: ELIOT@cs.umass.edu
- Date: Wed, 11 May 88 16:22 EDT
From: IN%"firstname.lastname@example.org.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
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
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
Consider (again) this code:
(defun fix-base-system (pkg)
(do-all-external-symbols (sym pkg)
(when (fboundp sym)
(proclaim (list 'constant-function sym))))))
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).