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

From: Matthew Flatt (mflatt at cs.utah.edu)
Date: Sat Oct 1 08:46:29 EDT 2005

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


 * 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


 * 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...



Posted on the users mailing list.