Can Common Lisp keywords have function definitions and properties?
In "Common Lisp -- The Language", Steele writes: "[Keyword] symbols are
used only as labels and never to carry package-specific values or
properties." This would seem to rule out properties. But it says nothing
about function definitions, and it doesn't sound very definitive.
The two implementations I've used have answered the question differently.
Hmmm.
In article <·······@hpdtczb.HP.COM> ·····@hpdtczb.HP.COM (Greg Weeks) writes:
>Can Common Lisp keywords have function definitions and properties?
I think they can, but it's a vary bad idea to put function definitions on
them. The whole point of the package system is to make sure that unrelated
programs don't accidentally use the same name for global variables or
functions. If two programs both decide to put function definitions on
keywords, then they may use the same keyword, and one will lose.
Properties are less of a problem, so long as the indicators are in the
application's package.
>In "Common Lisp -- The Language", Steele writes: "[Keyword] symbols are
>used only as labels and never to carry package-specific values or
>properties." This would seem to rule out properties. But it says nothing
>about function definitions, and it doesn't sound very definitive.
I believe the above quoted sentence is merely describing convention, and
was not intended to proscribe implementation behavior. In fact, "never to
carry package-specific ... properties" does not mean "never to carry
properties"; an application that manipulates Lisp programs might store data
about symbols seen in the program on the symbols' plists, and such data is
not "package-specific." The only requirement on implementations regarding
keywords is that they be constant global variables bound to themselves.
Also, I think implementations are not supposed to use keywords as property
list indicators on the user's symbols.
>The two implementations I've used have answered the question differently.
Good enough reason not to do it unless you really need to.
--
Barry Margolin, Thinking Machines Corp.
······@think.com
{uunet,harvard}!think!barmar