#

## Issue READER-ERROR Writeup

    Forum:		Cleanup
    Issue:		READER-ERROR
    References:	Chapter 3, "Syntax"
    		Section 2.2, "Types"
    Category:	ADDITION, CHANGE
    Edit History:   V1, 23 Oct 1989, Sandra Loosemore
    		V2, 02 Nov 1989, Sandra Loosemore
    			(change supertypes, update discussion)
                    V3, 10 Jul 1990, David Moon (include amendment from meeting)

    Problem Description:

    Chapter 3 of the current draft is not consistent about the types of
    errors that must be signalled by the reader.  In most places where it
    specifies that an error is to be signalled, it does not indicate a
    particular type of error, but in at least one situation it requires
    the error to be of type PROGRAM-ERROR, and in other cases it requires
    the error to be of type ERROR.

    None of the ERROR subtypes described in section 2.2 really seem
    appropriate for syntactic errors detected by the reader.  In
    particular, the description of PROGRAM-ERROR implies that its purpose
    is for errors relating to program syntax which are detectable during
    evaluation or compilation rather than read-time errors.  It seems
    especially inappropriate to use PROGRAM-ERROR for this purpose since
    the reader can be used to read things other than programs.  Likewise,
    STREAM-ERROR appears to have been intended to be used for errors
    relating to character-level transactions on the stream rather than
    lexical analysis or parsing.

    Proposal (READER-ERROR:NEW-TYPE):

    Add a new type specifier, PARSE-ERROR.  This is a subtype of the
    types STREAM-ERROR, ERROR, SERIOUS-CONDITION, CONDITION, and T.  The
    type PARSE-ERROR consists of serious conditions that relate to
    lexical analysis (the building and interpretation of tokens) and
    parsing (errors in reader macro syntax) by the Lisp reader.

    Since PARSE-ERROR is a subtype of STREAM-ERROR, objects of this type
    inherit a STREAM slot, which can be accessed using the function
    STREAM-ERROR-STREAM.

    Change the discussion in chapter 3 to specify that the type of errors
    signalled by the reader is PARSE-ERROR.  There are numerous places
    that would be affected.

    Rationale:

    The general policy that has been followed in other areas of the
    language where errors must, should, or might be signalled is to
    specify a particular subtype of ERROR which covers that class of
    errors.  Doing the same for reader errors would be consistent with the
    overall policy, but none of the existing error types seem appropriate
    for reader-related errors.

    Current Practice:

    LispWorks (from Harlequin) reportedly already uses such a condition.

    Cost to implementors:

    Trivial.

    Cost to users:

    Probably no user programs rely on the reader signalling any particular
    type of error yet.

    Benefits:

    Increased consistency in the language design.
    Ability to set up handlers specifically for reader errors.

    Discussion:

    Pitman says:
      Our later comments will show that i would like this condition to be
      called PARSE-ERROR so that it doesn't seem to be useful only for
      READ-related problems but can in fact be used for other parser-style
      applications (e.g., a FORTRAN parser, a user-written English-language
      interface, etc.).

    The initial version of this proposal specified that PARSE-ERROR was
    disjoint from (rather than a subtype of) STREAM-ERROR.  This was
    changed because there was a suggestion that some conditions should be
    both a PARSE-ERROR and a STREAM-ERROR.  Making it a subtype also allows
    it to inherit the STREAM slot and the STREAM-ERROR-STREAM accessor.

    Prior to version 3 the condition PARSE-ERROR was named READER-ERROR.

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