[plt-scheme] keywords (a backward-incompatible change)

With version 299.403, we plan to add keywords to MzScheme. Keywords are
self-quoting, symbol-like values that can be used for keyword-based
optional arguments.

For now, we've settled on colon-prefixed keywords --- which means that
a symbol or identifier can't start with an unquoted colon:

 (keyword? :a)   ; => #t
 (eq? :a ':a)    ; => #t
 (keyword? ':a)  ; => #t
 (keyword? 'a)   ; => #f
 (keyword? ':|a b|) ; => #t
 (keyword? '|:a b|) ; => #f
 (keyword? :)    ; => #t

 (symbol? :a)    ; => #f
 (symbol? :)     ; => #f

 (lambda (:x) 10) ; => syntax error: :x is not an identifier


Pros:

 * Self-quoting keywords support keyword-based optional arguments with
   a relatively standard syntax.

 * Syntactic forms can also use keywords, and pattern matching "just
   works". Using keywords can help clarify when a syntactic form
   expects to match literals (e.g., the colon in a `compound-unit/sig'
   form) versus bindings (e.g., `quasiquote' in a `match' pattern).

 * Some people like the idea of keywords, and they'll put them to good
   use.

Cons:

 * R5RS allows a colon at the beginning of a symbol/identifier, and
   some of our code uses identifiers that start with a colon. Adding
   keywords of this form is a significant backward-incompatible change.

 * Some people dislike the idea of keywords, and they'll be forced to
   use libraries that depend on keywords.

To help port code, `#k-' can be used in front of an S-expression to
disable keywords, just like `#ci' selects case-insensitive parsing. For
example, if a module uses colon-prefixed identifiers/symbols and the
module does not need keywords, then it can be prefixed with `#k-'.
Naturally, `#k+' would enable keyword parsing, so `#k+:apple' is always
the keyword `:apple'.


Assuming that we add keywords to MzScheme, a MzLib library will quickly
follow for defining procedures with keyword-based arguments. MzScheme's
built-in `lambda' and `case-lambda' will not change.


Among the people that I've polled so far, this plan has been relatively
uncontroversial; discussion quickly turns to the best uses keywords,
instead of whether they should exist or how they should be written. So
I'm broadening the poll here...

Opinions?


Matthew