[plt-scheme] Improvement in paren-checker algorithm

Hi,

   This may have already been addressed in the "syntax coloring and 
checker" thread that I haven't had time to read through, but I thought 
I'd mention it.  This is a (much condensed) piece of code that I'm 
working on  (it's not Scheme, it's ParentheC...)


(define-function (apply_th thnk)
                  (dbg "Apply-th")
                  (union-case thnk th
                              [(apply_literal k lit)  ;; **** line 1
                               (apply_k k lit)]         ;; **** line 2

                              [(apply_proc body arg env k)
                               (th_eval_exp body
                                            (envtype_extend arg env) k)]

                              [(eval_exp expr env k)
                               (dbg "Eval-exp-th")
                               (union-case expr exp
                                          ;; process throw
                                           [(throw varexp body) (apply_k 
k 0)
                                            ;; **
                                            ;; **
                                            ])]))    ;; **** line 3

Now, I had forgotten a close-parent on line (1).  This cause the 
close-bracket on line (2) to not match.  This causes a cascade, where 
*none* of the paren-pairs beyond there will match, all the way down to 
line (3) - which in the actual code is several screenfuls.  It didn't 
take me long to track down the missing paren by looking at what the 
largest bit that would match was, and where it broke down.  But it did 
leave me wondering a bit whether there was a bug in the algorithm, or 
strange characters getting in the file, or parens that weren't seen for 
some reason..  Not good thoughts to have.

   C is notorious for cascading errors (one missing semicolon on line 56 
and you get 1269 errors.  Add it back in, and you go down to *3* 
errors.  That's happened to me..)  Seeing as how DrScheme is a teaching 
environment (and the joke on LISP is that it's for "Lots of Insidious 
Silly Parentheses", the checker algorithm should be able to do the kind 
of "largest correct block" analysis that I did (starting from the 
beginning of the define-function block), to spot the root cause of the 
error.

PS. I'm reminded again why I don't like Chez..  I'm currently writing 
this in DrScheme because I like the interface and paren checker better 
than SWL (which doesn't work under Panther anyway), and then I have to 
test it under Petite Chez on the MacOSX command-line because ParentheC 
doesn't work under DrScheme (yet, we're working on it)..  It just 
reminds me too much of the old edit-compile-run cycle.  That and the 
fact that command-line Chez has an almost non-existent debugger - won't 
even tell you which *line* an unbound variable is on..  Now I know why 
Friedman says he doesn't use the debugger - because *you can't*!!