Issue: FUNCTION-DEFINITION (Version 1)

[gz@spt.entity.com (Gail Zacharias)]

Coral implements something like this proposal (under a different name) with
both the OPTIONAL and REQUIRED options.  The requiredness is controlled by a
user variable (*save-definitions*) which applies whenever a function is
created from a lambda expression (as opposed to being fasloaded).  This
includes at least calls to COMPILE and the newly popular (EVAL '(FUNCTION
(LAMBDA ...))) idiom.  Thus program-manipulating programs can ensure (by
binding the variable) that the lambda expression is preserved whenever it's
coerced to a function under program control, while users can turn off its
interactive effect (by setting the global value) if space is tight.

Note that we have an (optional) compiler-based evaluator, and not only does
this not speak against this proposal, it was the main motivation for our
providing this functionality in the first place.  And since one of the
effects of disallowing the application of lambda expressions is to make
program-creating programs behave as if they were in a compiler-based
implementation, most such programs will require this functionality now, and
each one would need to reimplement it if it's not provided by the language.

I strongly prefer a name like FUNCTION-DEFINITION over SOURCE-CODE, as the
latter can be confused with the textual source code (as in meta-.).

I would also prefer that FUNCTION-NAME be split off as a separate function
rather than being one of the values from FUNCTION-DEFINITION, especially if
the suggestion above about unifying the two options with a *save-definitions*
variable is adopted.  This is because recording of function names should
not be controlled by this variable.