[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
(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.