[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Hole
- To: RPG@sail.stanford.edu, cl-cleanup@sail.stanford.edu
- Subject: Hole
- From: Guy Steele <gls@Think.COM>
- Date: Mon, 8 Jun 87 10:27 EDT
- Cc: gls@think.com
- In-reply-to: <8706072326.AA12046@Think.COM>
It strikes me that the interaction of &optional and &required-key
arguments is dicey at best. It might be better to allow one or the
other kind of argument but not both in a single lambda-list.
I am also not crazy about the name &required-key; it is too obviously
the result of leaning over backwards to accommodate history.
An aesthetically more pleasing design that deals with both objections
is simply to use the existing keywords &key and &optional, with the
extension that &optional may occur *after* &key if desired. That is, it
is still true that each of &optional and &key may appear at most once in
an argument list, but they may appear in either order. Thus &key marks
the transition from by-position to by-name, and &optional marks the
transition from required to optional. One may then have either of two
patterns:
(defun blah (x y z &optional p q r &key a b c) ...)
----- ----- -----
| | |
| | optional named
| optional positional
required positional
(defun blee (x y z &key p q r &optional a b c) ...)
----- ----- -----
| | |
| | optional named
| required named
required positional
Thus required named and optional positional cannot be mixed,
and no new keyword is needed. The only unfortunate aspect of
this proposal is that it is incompatible with previous practice.
Currently
(defun blaw (x y z &key a b c) ...)
treats a, b, and c as optioal named parameters, whereas this
new proposal would treat them as required.
--Guy