[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: do-nothing macro generates nil nevertheless
- To: firstname.lastname@example.org
- Subject: Re: do-nothing macro generates nil nevertheless
- From: email@example.com (Barry Margolin)
- Date: 28 Feb 1995 02:08:38 -0500
- Organization: NEARnet, Cambridge, MA
- References: <firstname.lastname@example.org>, <email@example.com>, <firstname.lastname@example.org>
- Sender: email@example.com
In article <firstname.lastname@example.org> Erik Naggum <email@example.com> writes:
>the compatibility note on page 543 also includes a note that MacLisp and
>Interlisp had splicing macro characters that could splicing of arbitrarily
>many values. I think I understand this, but maybe somebody can tell me why
>was this capability removed from Common Lisp?
Because all the uses the CL designers had ever heard of only depended on
returning 0 or 1 values -- they were all variants of #+ and #-. So they
decided to simplify the mechanism to this special case. I know this isn't
in the "kitchen sink" spirit of Common Lisp, but at the time this spirit
hadn't quite matured.
It also simplifies the reader algorithm. With the 0-or-1 value
restriction, it's very simple to specify that the reader simply starts over
if a macro character returns zero values, and returns immediately if it
returns one value. If multiple values were permitted, the reader would
have to be able to save away the extra values to be read by successive
calls to READ on that stream. I'm not sure what the right behavior should
be if the next input function on the stream isn't a call to READ.
Alternatively, this splicing could be specified as only being permitted
within a call to READ-DELIMITED-LIST, and then the reader algorithm would
have to be complicated by specifying this interaction.
BBN Internet Services Corp.