A keyword data type

["mike@gold-hill.com after 1-April-88" <mike%acorn%live-oak.lcs.mit.edu@ICS.UCI.EDU>]

    Date: Sun, 06 Mar 88 12:08:16 -0800
    From: kipps%etoile.uci.edu@ICS.UCI.EDU
    
    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.

....mike beckerle
Gold Hill