Comment 6 for bug 922952

>
>
> Douglas: is this just an irritating quirk, or are you getting bad code
> due to this?
>

I would say "suboptimal code", but we worked around it.

Our codebase uses keywords as proxies for unprintable hairy structs, so you
when we write this-
  (perform-complex-operation-on :some-keyword ...)
it means
  (perform-complex-operation-on (load-time-value
(internalize-a-hairy-struct-named-by :some-keyword)) ...)
where there is slightly less overheard than the same function on an
argument of unknown compile-time type.

A naive implementation as a compiler macro is unable to see this "easy"
case -
  (perform-complex-operation-on (if (some-hairy-test) :some-keyword
:some-other-keyword) ...)
so I improved that with a deftransform which works fine for (MEMBER
:some-keyword :some-other-keyword).

But I needed a deftransform that could handle any keyword since it's often
impossible to enumerate the set of set of symbols at the time I define the
transform - but it is still true that a keyword can be efficiently handled.
 It was then that I discovered that KEYWORDP is essentially "never known to
be true" at compile-time; and moreover, by proclaiming the function's ftype
(KEYWORD ...), it helps not much - you end up receiving an lvar of type
  (AND (satisfies keywordp) (member :really-i-am-keyword)) ; this seems
superfluous !

I ended up writing a transform for type T. Its body detects that it's first
lvar is (member ...), the constituents being symbols naming complicated
objects, or give up. That did what we needed, but I wanted to report the
issue of it being basically impractical to write a transform matching on
KEYWORD type.