[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- To: ELIOT@cs.umass.edu
- Subject: Constant-Function
- From: Jon L White <firstname.lastname@example.org>
- Date: Thu, 12 May 88 21:36:45 PDT
- Cc: email@example.com
- In-reply-to: ELIOT@cs.umass.edu's message of Wed, 11 May 88 16:22 EDT <8805120817.AA05875@edsel.lucid.com>
re: Consider (again) this code:
. . .
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? ...
The very question as to whether such a declaration would be at all useful,
as well as the degree of its utility, depends on how an implementation does
function-to-function interfaces. Few people in the common lisp community
have been desirous of imposing particular Lisp-system implementation
techniques into the portable standard; thus it's not surprising that few
are interested in standardizing on implementation specific tricks.
On the other hand, what is useful about the "constant-foldable" declaration
is that the transformation (sqrt 2.0) ==> 1.414... is independent of how
any Lisp system (or compiler) is built [except to the degree that you view
this as a "compiler optimization".] User-level macros can do the same
thing, but probably less thoroughly than the compiler. It only depends
upon knowing some simple properties about the function SQRT.
Also, the type system in Common Lisp isn't purely a "compiler efficiency"
hack; although I'm not aware of a really good "type inferencing" CL
compiler, this declarational information can be used in the sense of
"strong typing". Thus its justification is not merely that fixnum
declarations can make compiled code run faster. [But I admit that there
are so many systems wanting at least some type declarations for efficiency
that a few lone "hold outs" against them probably couldn't prevent their
appearance in CL].
Perhaps "block compilation" is a better line of pursuit since it has some
implications for "modularity" as well as potential for code efficienty.
Note that lots of somewhat-incompatible redefinitions of functions don't
invalidate FTYPE, or INLINE, or "constant-foldable" assumptions; but they
would invalidate the definition you have given (again!) for "constant
function", i.e. that it merely means "I won't redefine this function at
runtime". [This is the point you said didn't make sense to you; I'm sorry
I don't know how to put it in any plainer words]. Thus even in an
implementation whose compiler could profit from such information, the
declaration seems like overkill because it is too easy to violate its
contract without violating any useful requirement. It needs to be more
specific (thus I would call it "vague" for not being that specific).
Note also that there is a proposal to the x3j13 "cleanup" committee to make
it an error to redefine any function named in the Lisp package; this would
cover your case (fix-base-system 'lisp). But the proposal is not particlarly
for the purpose of enabling potential compiler tricks; rather (I think) it
is for the purpose of facilitating reasonable standards for code sharing.
I.e., how can you absorb my portable code that uses lisp:append if you have
redefined it to do something totally different.
-- JonL --