[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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
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
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.