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)
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.
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
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.
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.
LispWorks (from Harlequin) reportedly already uses such a condition.
Cost to implementors:
Cost to users:
Probably no user programs rely on the reader signalling any particular
type of error yet.
Increased consistency in the language design.
Ability to set up handlers specifically for reader errors.
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
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.