[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
A keyword data type
Date: Sun, 06 Mar 88 12:08:16 -0800
The comments I've heard so far about keywords lead me to believe that
there shouldn't be a keyword package at all; instead, there should be a
keyword data type, i.e., a data type of symbolic literals. A keyword data
object always evaluates to itself and has only one user-visible component,
its print name.
Frankly, I think this is a great idea. However, there are interactions with
various features. E.G., &key parameters. For the sake of
language extensions like CLOS, the identifiers for &key parameters are
not really going to be required to be "keywords" at all; rather, they
can be any symbol in any package. Use of real "keywords" for this just
saves making an extra symbol. We would need to change terminology
so that &key would become &name or &sym or something to avoid confusion.
A variation of your idea which might capture its value and yet avoid
turmoil in the CL world would be to make KEYWORD officially a subtype
of SYMBOL, and to exactly define which symbol operations work on this
subtype. My suggestion is that SYMBOL-NAME work, but not
SYMBOL-PLIST, SYMBOL-FUNCTION, SYMBOL-VALUE, etc. Currently, keywords
are real symbols, not a subtype, and therefore the issue arises of
whether you can IMPORT a keyword, etc.