[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Detecting mismatched parens better
- To: RMS at MIT-AI
- Subject: Detecting mismatched parens better
- From: David L. Andre <DLA at MIT-AI>
- Date: Wed ,20 Jan 82 12:36:00 EDT
- Cc: BUG-LISPM at MIT-AI, DLA at MIT-AI
I think you're idea is a kludge in general, but I am not against
something being done if you think it is important.
I do not, however, think that the reader is the right place to hack
this. It is unnecessarily complicating the syntax of LISP, to say that
indentation is enforced by any certain hairy scheme. I often type
things to the interpreter which are incorrectly indented, because I feel
no need to indent them correctly. Your proposal would bomb out for me
there. You could have the compiler call a special flavor of the reader
which has these hacks, I suppose.
As for your idea that the compiler shouldn't bomb out given bad input,
and should continue with the rest of the file if at all possible, this
has been discussed before, in the context of macroexpansion. The
conclusion reached was that it was probably best to have a switch
controlling whether the compiler should punt or bomb out on
macroexpansion errors. Many people, myself included, would just as soon
want to change the source as soon as we get fatal errors, rather than
find that we wasted the time of of an entire compilation.
As an alternative to your proposals, consider the following:
First, the reader errors should be changed to be more descriptive. It
is probably sufficient to append something like "Your parentheses are
unbalanced" to the current error messages.
Second, It would be fairly simple for editors (trivial for ZWEI) to
check parens before or during writing of LISP mode buffers. If the
parens don't balance, a warning could be printed, and the user could be
given the option to proceed.
Finally, if you want, a punt/bomb switch could be put into the compiler
which would cover both macroexpansion and reader errors. But the
current default behaviour shouldn't be changed. The first two changes
should take away the necessity of changing the reader.