don't unconditionally unparse CHARACTER-SET types into MEMBER types
Doing so means dumping a list containing most of unicode for each
function that return something like
(code-char (+ <const> <(integer 0)>))
which has a derived type (CHARACTER-SET ((<const> . 1114111))).
Instead, pick whichever is more compact, using number of characters
vs number of character code ranges as the deciding factor.
This means that users can see SB-KERNEL:CHARACTER-SET types in
eg. output from DESCRIBE or as return values from
SB-INTROSPECT:FUNCTION-TYPE -- which is suboptimal, but less bad
than such types slowing us down as horribly as they do prior to this
change.
At some point, however, we should document and export SB-EXT:CHARSET
or something -- but I don't want to think of the issues associated
with a public interface right now.
commit 33564311979de0c b8798884c377e49 1cfb416b95
Author: Nikodemus Siivola <email address hidden>
Date: Fri May 4 12:43:40 2012 +0300
don't unconditionally unparse CHARACTER-SET types into MEMBER types
Doing so means dumping a list containing most of unicode for each
function that return something like
(code-char (+ <const> <(integer 0)>))
which has a derived type (CHARACTER-SET ((<const> . 1114111))).
Instead, pick whichever is more compact, using number of characters
vs number of character code ranges as the deciding factor.
This means that users can see SB-KERNEL: CHARACTER- SET types in INTROSPECT: FUNCTION- TYPE -- which is suboptimal, but less bad
eg. output from DESCRIBE or as return values from
SB-
than such types slowing us down as horribly as they do prior to this
change.
At some point, however, we should document and export SB-EXT:CHARSET
or something -- but I don't want to think of the issues associated
with a public interface right now.