[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: Alan Bawden <ALAN at MIT-MC>
- Date: Thu ,21 Jan 82 01:44:00 EDT
- Cc: BUG-LISPM at MIT-AI
I don't like your proposed paren hack:
1) First off, I find "( eval-when" un-aesthetic.
2) It makes certain formerly legal printed representations of lisp
objects now generate errors. I don't like adding the collumn position
of a parenthesis to the syntax of the language as understood by READ.
3) It doesn't really work reliably. Consider:
( eval-when (eval compile)
(defun foo ()
(let ((base 10.) ;missing close paren here
(print *foobar*))))
(defun bar ()
...)
The missing close paren simply causes the rest of the forms in the
file to be treated as if they were inside the eval-when, there is no
way to tell what the user intended in this case. I would rather have
the compiler read through to the end of the file and get an error,
than have some hack go off when the next
( eval-when ...
is encountered that decides (incorrectly) to supply the close paren
right then and there and procedes with the compilation.
I cannot imagine that I would ever simply allow something like this to
supply close parens for me. I would certainly be so suspicious of
whatever it had done that I would fix up the paren error in my file
and then recompile the wrole file beyond that error. Since that is
almost exactly what I would do today in that case, and since today
that syntax error would be found immediately and no additional
compilation would happen, I see no benefit to the mechanism.