Re: &function

[Barry Margolin <Margolin@HIS-BILLERICA-MULTICS.ARPA>]

    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...

If a global variable is holding a function, the right place to put it is
in the function cell, not the value cell.  The analogy here is that
"&function symbol" is to "defun symbol" as "symbol" is to "setq symbol".

What you didn't mention, but perhaps meant to imply, is that FUNCALL
would still be required when the function is in a computed location,
such as on a property list.  Scheme would allow
          ((get symbol indicator) args)
but Common Lisp with &function still wouldn't.  I will grant you this.

       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).

Those of us who believe in two namespaces feel that the distinction
between function names and variable names is more important than the
distinction between integers and floats.  Even for heavy users of
functional programming, I'm sure that most of the time functions are
called, not passed around as data.

    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?

Have you read KMP and RPG's paper, "Issues of Separation in Function
Cells and Value Cells"?  It gives the many arguments on both sides of
the issue.  It is document X3J13/86-010, and it was sent out to all
X3J13 members before the December meeting.  If you are not a member, you
can probably get a copy from someone who is (Scott Fahlman is the only
CMU person who comes to mind immediately).

    I think the burden of
    proof should be on the people supporting the more complex scheme.  (No
    pun intended.)

I think that the burden of proof should be on the people favoring
changing the language.  Common Lisp is mostly descended from a long
line of two-namespace dialects, it is already building a strong
following, so an incompatible change of this magnitude should only be
made if the language without the change is severely deficient.  People
have been doing significant programming in MacLisp and Zetalisp for two
decades, so I don't think the two namespaces limits the usefulness of
the language greatly.
                                        barmar