[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Issue: FUNCTION-TYPE (Version 5)
- To: CL-Cleanup@sail.stanford.edu
- Subject: Issue: FUNCTION-TYPE (Version 5)
- From: Barry Margolin <barmar@AQUINAS.THINK.COM>
- Date: Wed, 17 Jun 87 11:40 EDT
- Cc: X3J13@sail.stanford.edu, Masinter.firstname.lastname@example.org
- In-reply-to: <870616-155121-101@Xerox>
I think STRICT-REDEFINITION is reasonable, although I think I would
probably vote for COERCE-REDEFINITION because it has less impact on
The STRICT-REDEFINITION proposal would require some additional changes
to user code. An explicit coercion would have to be added whenever a
symbol or lambda expression is used as a functional argument. Many such
cases can be identified at compile time, but not all. One strategy for
automatic conversion is to replace every call to FUNCALL, APPLY, etc.
with a call to an equivalent function or macro that tests the functional
argument at runtime and coerces the argument to a true function if
necessary. If implemented carefully, this should not cost significantly
more than doing a built-in coercion within FUNCALL and APPLY.
There is also a big hole in STRICT-REDEFINITION as currently proposed.
This paragraph suggests that one might coerce a symbol or lambda list to
a function at runtime, but the proposal doesn't mention any new function
that one would call to do this. There needs to be a MAKE-FUNCTION
function, which takes a symbol or lambda list and returns the
corresponding function. It probably should have an optional environment
argument, too. It might be equivalent to
(defun make-function (thing &optional env)
(eval `(function ,thing) env))
However, it should probably be a primitive so that implimentations can
do it optimally.