>
>
> 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.
>
>
> 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 complex- operation- on :some-keyword ...) complex- operation- on (load-time-value a-hairy- struct- named-by :some-keyword)) ...)
when we write this-
(perform-
it means
(perform-
(internalize-
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" complex- operation- on (if (some-hairy-test) :some-keyword keyword) ...) keyword) .
case -
(perform-
:some-other-
so I improved that with a deftransform which works fine for (MEMBER
:some-keyword :some-other-
But I needed a deftransform that could handle any keyword since it's often i-am-keyword) ) ; this seems
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-
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.