&function

[Timothy.Freeman@theory.cs.cmu.edu]

   I'm not sure I really agree that it is a significant deterrent, and
   there are reasonable arguments in favor of requiring FUNCALL, but for
   the purpose of this discussion let's assume that it is.

Each irregularity of the language requires some effort to learn.
Since normal variable evaluation is much more common than funcalls,
the requirement to learn the semantics of funcall is an deterrent to
using it.  Unless there is some benefit gained from the irregularity,
it shouldn't exist.

   The keyword &function in the lambda list indicates that the functional
   interpretation of the following parameter should be bound, rather than
   the value interpretation.  This is analogous to the distinction between
   LET and FLET.

Okay, but this only eliminates the funcall's for variables which
appear as arguments.  What about variables that are not arguments?  Is
there any reason it should be easier to invoke a function object that
came in as an argument than one that didn't?  More irregularities in
our language...

   This keyword also serves a secondary function, that of documenting the
   fact that a particular parameter is expected to be a function.  This is
   useful for programmers, and compilers can also assume a default
   declaration for the parameter.

Is there some reason we need documentation that a variable is a
function but we don't need documentation that a variable is an
integer?  This is an argument for going to a strongly typed language
(or one that has a very irregular structure).

I think the one-namespace arrangement is easier to understand and use
than what we have now.  Does anyone have any explanation of why the
double-namespace arrangement should be kept?  I think the burden of
proof should be on the people supporting the more complex scheme.  (No
pun intended.)