#

## Issue PARSE-ERROR-STREAM Writeup

    Status:		Version 3 passed, 6/8/90

    Issue:		PARSE-ERROR-STREAM
    Forum:		Cleanup
    References:	Condition System, Version 18
    		Issue READER-ERROR
    		Issue CLOS-CONDITIONS
    Category:	CHANGE/CLARIFICATION
    Edit History:	Version 1, 1/3/90 by Kim A. Barrett
    		Version 2, 6/6/90 by Kim A. Barrett
    		Version 3, 6/11/90 by Kim A. Barrett (X3J13 ammendments)

    Problem Description:
      The recently passed issue READER-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.

    Proposal (PARSE-ERROR-STREAM:SPLIT-TYPES):

      1. Define that 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.

    Rational:
      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.

    Current Practice:
      PARSE-ERROR is sufficiently new that few implementations are likely to
      have added it.

    Cost to Implementors:
      Should be trivial.

    Cost to Users:
      If this does not passe then some programs which might otherwise reasonably
      signal PARSE-ERRORs will not be able to do so.

    Discussion:
      Barrett supports 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.

Copyright 1996-2001, Xanalys Inc. All rights reserved.