[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- To: Barry Margolin <Margolin@bco-multics.arpa>
- Subject: &function
- From: Timothy.Freeman@theory.cs.cmu.edu
- Date: Wed, 14 Jan 1987 22:45:00 -0000
- Cc: firstname.lastname@example.org
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
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