From ... From: Erik Naggum Subject: read-time conditions Date: 1999/04/09 Message-ID: <3132649180002795@naggum.no>#1/1 X-Deja-AN: 464408383 mail-copies-to: never Organization: Naggum Software; +47 8800 8879; http://www.naggum.no Newsgroups: comp.lang.lisp 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