Issue: FUNCTION-TYPE (Version 5)

[Barry Margolin <barmar@AQUINAS.THINK.COM>]

I think STRICT-REDEFINITION is reasonable, although I think I would
probably vote for COERCE-REDEFINITION because it has less impact on
existing code.

    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.

						barmar