[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
call-next-method: More feedback from Symbolics reviewers
- To: Common-Lisp-Object-System@sail.stanford.edu
- Subject: call-next-method: More feedback from Symbolics reviewers
- From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
- Date: Thu, 5 Feb 87 01:01 EST
- In-reply-to: <870204-212007-1602@Xerox>
Date: 4 Feb 87 21:20 PST
From: Danny Bobrow <Bobrow.pa@Xerox.COM>
In the current version of the document, CALL-NEXT-METHOD is
documented as a macro. That was a mistake; it should be a
We need a proposal for the extension for call-next-method for changed
arguments. What is the problem with providing call-next-method with an
&rest argument, and if it is non-null, then argument checking is done on
those elements of the argument-list that have been used in the
No problem, that's what I had in mind. The only reason it's not in is
that someone wouldn't let me put it in because the proposal wasn't lean
enough. Maybe it's time to put it in now?
Does this argue for a macro implementation to allow
alternative expansions in the case where arguments are provided.
That was my idea at first, but it was firmly pointed out to me that
issues of optimization should be separated from issues of semantics.
Implementations can surely figure out how to make their compilers notice
whether arguments are provided or not, and generate different code.
One way is to declare the FLET function INLINE and constant-fold the
conditional inside the function that checks whether arguments were