Keywords as messages

[Kent M Pitman <KMP @ MIT-MC>]

Thus far, no one has suggested that message keys be keywords.  In fact,
people have been using packaged message names, which pleases me.

I wish to explicitly suggest that we encourage that message keys not be
keywords (ie, symbols on the keyword package).

If you agree with me that message sends should be syntactically
indistinguishable from function calls, then it should be obvious that
keywords would be a bad idea for messages, since I imagine people
wouldn't be happy with notation like (:CLEAR-SCREEN w).

Another reason, though, is that you cannot know at the time you make an
abstract type what whether it will ever parent other types and whether
such parentage will result in name collisions. Name collisions should
occur only when the two names are methods implementing the same protocol
(in which case, generally, both methods are doing roughly the same thing
and it matters a lot less that one of the methods is shadowed).
Keywords have no potential for scoping, so if code on two modules want
to produce flavors which handle messages named FOO, they can't both call
them :FOO without colliding for fear someone will mix the two flavors
and be able to access only one of the two methods.  I recommend that we
actively encourage that they be called JOE:FOO, BILL:FOO, etc.
In general, keywords should not be used in any context where the 
space of identifiers is not fixed and non-extensible.

Current custom in LispM and NIL flavors is to use keywords as 
message names. In some cases (particularly with generated message
names for reading/setting variables), the semantics of the provided
primitives is such that using non-keywords is likely to lead to
trouble. This is a problem that should be cleaned up before any
flavors package is adopted for CL distribution.
-kmp