[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
extra lambda list keywords
Date: Thu 10 Jul 86 14:18:40-MDT
From: SANDRA <LOOSEMORE@UTAH-20.ARPA>
I just noticed the bit on p. 65 of the manual where it says:
"Implementations of Common Lisp are free to provide additional lambda-list
keywords."
Is this *really* useful to any implementation? Although you can supposedly
find out about the additional keywords from the lambda-list-keywords constant,
allowing implementation-specific crud to appear in lambda lists seems like
another good way to frustrate would-be implementors of portable code walkers.
In particular, I'm concerned that if implementations try to extend the syntax
of what can appear in lambda lists, code walkers would have a very hard time
identifying default values and other bits of evaluable code in the lambda
list. Not to mention that a routine that tries to parse lambda lists could
get very confused if, for example, it found a strange keyword &foo sitting
where it expected to find only an &rest or &key.
What's this talk about portable code walkers. You can't write portable
code at all if you use implementation-specific lambda-list keywords, let
alone portable code walkers.
Historically, I think LispMs did (some may still) have lambda list
keywords &SPECIAL and &LOCAL, whose effects are somewhat obvious by
their names. There was also "E, which effectively defined a special
form, because the argument was automatically quoted. There was also an
&FUNCTIONAL which I think was like "E except that it wasn't quoted
as data, it was quoted as a function. For example, this is how it soft
of behaved:
(defun foo1 ("e bar1 &functional baz1)
(list bar1 baz1))
(foo1 car cdr) =more-or-less= (list 'car #'cdr)
There was also a &LIST-OF for macros. See some old LispM documentation
if you really care.
The above may not be completely accurate, but you get the idea. I agree
that extending lambda-list keywords should be done carefully and for
very good reasons.