Re: Issue: FUNCTION-NAME (Version 1)

[David N Gray <Gray@DSG.csc.ti.com>]

> 13. Declare that any function name is a suitable argument to FUNCALL and
>     APPLY.  In such a case, the function name is passed to FDEFINITION,
>     and the result (which may in turn be a function name) is called.

I don't think this is such a good idea.  The case of automatically coercing
a symbol to a function is needed because it provides a portable mechanism
for indirect addressing of a function; I haven't seen a reason to need this
for non-symbol function specs.  But more important is that coercing a
symbol to a function is a trivial operation that is reasonable to do at
run time on each call without adding a significant amount of overhead.
FDEFINITION, on the other hand, is a much more expensive operation -- at
best it might use GET to do a property list lookup, or it could be using
string-append and INTERN to convert the name to a symbol.  In either case,
I think this is more work than you want to do on each call.

> 12. Declare that any lamba expression (i.e., a list whose car is LAMBDA and
>     whose cdr is a well-formed lambda argument list and body) is a function
>     name.  The effects of the function name accessors on lambda expressions
>     are as follows.  FDEFINITION returns an implementation-defined value which
>     is the function specified the lambda expression, closed in the global
>     environment.  This FDEFINITION value cannot be changed by SETF.
>     FBOUNDP always returns T, and MAKUNBOUND is an error.

The exceptions for SETF and MAKUNBOUND show that this is not really as
consistent as you might like.  Furthermore, the FUNCTION special form would
have to treat a LAMBDA expression as a function, not a function name, in
order for it to be lexically scoped.  It seems like this might just cause
confusion rather than consistency.