Comment 2 for bug 994487

commit 33564311979de0cb8798884c377e491cfb416b95
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
      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.