Comment 2 for bug 994487

Nikodemus Siivola (nikodemus) wrote :

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

      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.