[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
LAMBDA proposals and counter-proposals
- To: MOON at MIT-AI, Guy.Steele at CMU-10A, EAK at MIT-MC
- Subject: LAMBDA proposals and counter-proposals
- From: Kent M. Pitman <kmp at MIT-AI>
- Date: Thu ,1 Oct 81 19:49:00 EDT
- Cc: LISP-FORUM at MIT-AI
There are MANY issues being addressed at once here. In the end,
all will have to be addressed. However, it might be of help for
people to clearly argue for or against one issue at a time, rather
than mixing them. Here is a sampling of the kinds of issues that
I feel are becoming too confused with each other; I think discussing
the sub-issues separately will help us build a better foundation for
a later discussion of the whole issue -- I fear we are currently trying
to solve too much all at once...
* HOW SHOULD EXTENSIONS BE INTRODUCED INTO THE LANGUAGE? If we
have one hairy construct to which we continue to add subtle,
concise additions to, is that the right thing? (eg, the
introduction of new &keywords) Or are we better off with slightly
more verbose constructs each of which has an independent function?
(eg, using LET instead of &AUX, LOCAL-DECLARE instead of &SPECIAL,
This question is made more complex by the possibility of making
DEFUN and perhaps even LAMBDA macroexpand from concise though
syntactically hairy constructs into larger but syntactically
more transparent underlying forms. ie, one might write
(DEFUN F (X &AUX Y) ...) but get (DEFUN F (X) (LET* (Y) ..)).
This is an important issue because it decides whether Earl's
note about his concern over extensibility is worthwhile to consider.
It is only worthwhile to worry about boxing yourself into a corner
with respect to extension if you believe that extension comes from
modifying existing operators/special-forms rather than creating
new ones. This is an issue for which I do not believe we have
a clear answer.
* WHAT EVEN BELONGS IN THE LAMBDA LIST? My feelings are that
a lambda list is a place for naming formal quantities that are
not known about locally. There are surely opposing viewpoints.
There are several isolatable sub-issues:
* &AUX variables are of a clearly different nature and do not,
in my opinion, have any business being in the lambda list at all.
* Destructuring. Is this part of the specification of the formal
quantities or not? I am very wishy-washy about this, but lean toward
the side of not wanting it in the bound variable list.
* What about advice to the evaluator? This has separable sub-issues
* Eval/Quote information.
This has to do with stuff that is to be done before the lambda
expression ever gets hold of things, so is not rightly part of the
things the lambda should contain. eg, fine if DEFUN wants to know
about "E and you want to type in (DEFUN F (X "E Y) ...)
but I would prefer that this macroexpand into
(PROGN (ASSOCIATE-EVALUATION-INFORMATION 'F '(EVAL QUOTE))
(SETF #'F #'(LAMBDA (X Y) ...)))
keeping the actual lambda list clear of such worthless clutter.
It is silly for an anonymous lambda expression to bother holding
onto information about EVAL and QUOTE since it can't do anything
useful with it.
Information about keywords and how to handle them correctly
is VERY complex and I don't think there is any kind of good theory
of that available at all. I would recommend not cluttering primitive
lambda lists with keyword information that is not well-agreed to be
the obvious right thing.
* Declarations, Argument type-checking
This hasn't been recently addressed by anyone, but probably should be.
These kinds of things may want to happen elsewhere besides at binding
points, so need special forms like LOCAL-DECLARE, DECLARE, etc. Having
their own special forms, is it reasonable to clutter the bound variable
list with a new notation for inferring things that could already be
* Kinds of bindings: &FUNCTION, &SPECIAL, ...?
Where do these belong? Are they part of the specification of the
formal quantities? Is &FUNCTION F anything more than another
dimension on the namespace issue? Should it be treated as such?
* HOW SHOULD SYNTAX MANIFEST ITSELF IN A LANGUAGE?
Dave gives me the impression that he feels that infix syntax
at the lowest level is acceptable if it buys convenience. There are
others who clearly do not see that this should be so. The LOOP
macro buys such syntactic convenience without any modification to
the notion that the underlying representation can be parse-free.
Even Pratt's CGOL, which redefines all of the syntax of Lisp in a
rather questionable way, does not have any problem coming up with
appropriate parse-free underlying representations. Whether the lowest
level of the language must be something one can fathom only with the
aid of a parser or not seems to be of critical importance.
As a closing note, I should add that I muchly support GLS's alternate
lambda list proposal. I have had similar ideas in the past and
I feel that any loss of expressive power it has can be made back up
primarily by use of other existing primitives (like LET, DECLARE, ...)
and possibly introduction of a small number of new primitives with
special-purpose tasks. I also agreed with DLW's recent reply to EAK's and