PARSE-ERROR-STREAMREADER-ERROR defined the new condition type PARSE-ERROR as a subtype of STREAM-ERROR. This means that PARSE-ERROR inherits behavior on the function STREAM-ERROR-STREAM, and has :STREAM as the associated initarg. The description of STREAM-ERROR can be read to imply that the value of STREAM-ERROR-STREAM is in fact a STREAM. That is, that (TYPEP (STREAM-ERROR-STREAM c) 'STREAM) -> true. However, it is fairly easy to imagine a program which might want to signal PARSE-ERROR under some circumstance, but which is not using a Common Lisp stream as its source of input.PARSE-ERROR has the class precedence list (PARSE-ERROR ERROR SERIOUS-CONDITION CONDITION T) thus making it no longer be a subtype of STREAM-ERROR.
2. Define a new condition called READER-ERROR, with class precedence list (READER-ERROR PARSE-ERROR STREAM-ERROR ERROR SERIOUS-CONDITION CONDITION T).
Issue READER-ERROR (version 3, passed 11/89) specified that the reader was to signal errors of type PARSE-ERROR for serious conditions that relate to lexical analysis (the building and interpretation of tokens) and parsing (errors in reader macro syntax) by the Lisp reader. Change this to instead specify that the reader signals errors of type READER-ERROR for such situations. There are numerous places (especially in chapter 3) that would be affected.
SPLIT-TYPES fixes the problem in the obvious way. If a program needs a condition which inherits from both is desired, such a condition can be trivially defined, since issue CLOS-CONDITIONS says that we now have multiple inheritance for conditions.PARSE-ERROR is sufficiently new that few implementations are likely to have added it.SPLIT-TYPES. He had some qualms about the merging when he first saw the READER-ERROR issue, but didn't have time to think about it much before the issue was voted on.