[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- To: firstname.lastname@example.org
- Subject: Constant Functions
- From: Barry Margolin <barmar@Think.COM>
- Date: Sun, 8 May 88 00:07:09 EDT
- Cc: ELIOT@cs.umass.edu, email@example.com
- In-reply-to: Jon L White's message of Sat, 7 May 88 03:13:06 PDT <8805071013.AA05614@bhopal.lucid.com>
Date: Sat, 7 May 88 03:13:06 PDT
From: Jon L White <firstname.lastname@example.org>
I think you may have missed the thrust of my critique of Eliot's proposal.
It sarted out like this:
Isn't it the case that *any* proclaim about a function is equivalent to
saying that that aspect of the function is "constant"?
I didn't address that part of your message in my response because I
agreed with it. That didn't seem to be the main thrust of your
message, though; you then went on to describe in detail a particular
type of optimization that seemed to be what you thought he was
Basically, a compiler can't make *any* assumptions at all about a function
it is compiling a call to without assuming "constant-function" also. This
is as true of FTYPE and INLINE declarations as it would be for the more
limiting items you mention like number of required arguments, etc.
This is not true. If there has been an FTYPE declaration, the
compiler may make assumptions about the types of arguments and values
of a function, but certainly not about the implementation.
Similarly, an INLINE declaration must already imply "constant function";
but my critique claims that a general "constant function" declaration must
not by itself imply INLINE.
He merely suggested that "constant function" + speed=3 + space=0 might
cause a compiler to open-code. Remember how he first introduced his
idea: he wanted a declaration that encompassed everything that INLINE
does, except that it wouldn't FORCE open-coding. However, a compiler
might decide to open-code based on other factors, such as optimization
Of course, it should be ok to redefine a "constant function" providing the
particular assumptions made during compilation aren't changed. That leaves
very little you can do to a function that has been inline'd.
Or to a function that has been declared CONSTANT-FUNCTION.
re: That's already not true of the VALUES declaration. It specifies an
attribute of the function being defined, just as Eliot was suggesting
CLtL, p162 speaks of the VALUES declaration; it says nothing at all like
that. Would you like to try again to say what you meant? Remember also
that Eliot was suggesting that a such a declare be equivalent to a proclaim
(which modifies a global database) and that would give it indefinite scope;
but every other declare is lexically scoped.
Sorry, I was thinking of Symbolics's VALUES declaration. They allow:
(defun fun (arg)
(declare (values name1 name2))
Symbolics has a large number of declarations that specify aspects of
the function being defined. However, I now realize that none of the
standard CL declarations behave like this.