Subject: read-time conditions
From: Erik Naggum <erik@naggum.no>
Date: 1999/04/09
Newsgroups: comp.lang.lisp
Message-ID: <3132649180002795@naggum.no>

  in a protocol I have designed, I use straight Lisp forms for the syntax,
  and use the Common Lisp reader to handle the input.  to make this secure
  and simple, I use a special readtable with limited capabilities.  to
  avoid a _lot_ of reimplementation, I handle conditions that crop up
  during parsing, and most of them are easy to handle correctly.  however,
  there is no restriction on the number of lines in a form, so I have to be
  able to continue to collect lines.  to ensure syntactic integrity of the
  form, I bind *READ-SUPPRESS* to T and try to read it.  if this succeeds
  without error, at least the syntactic structure of the form is intact,
  but if an END-OF-FILE error occurs, there is no meaningful distinction
  between a missing internal delimiter and a missing outermost delimiter,
  and I'm not sure I want there to be, but it means that I can't stop
  reading more lines when a human would clearly see an unterminated string
  and a properly terminated list.  this is annoying, since the system will
  just sit there and wait for more input until it times out.  however, one
  problem remains completely unsolved.

  most errors during reading can be dealt with by preventing them from
  happening in the first place.  some can't, by virtue of the integrated
  parser for symbols and numbers.  despite the rather simple protocol, I
  have to deal with package errors and numeric errors signaled in this
  reader function.  the errors are signaled in cases like these:

    FOO:BAR		(not external)
    FOO::BAR		(no package)
    34/0		(division by zero)
    1s999		(range error)

  I think an error message should be as complete as possible, so I'd like
  to report which unacceptable character string caused the error, but this
  has turned out to be excessively hard.  also, if there are more errors in
  the same list, only the first can be reported, because it's hard to move
  past individual elements.

  so, my question: should the reader signal errors of type READER-ERROR,
  only (which may be augmented to contain the actual string with the
  problem), or is it free _not_ to catch any other error that might be
  signaled by a function it calls to construct an object?

#:Erik