[plt-scheme] Improvement in paren-checker algorithm

Thanks for the detailed situation.

The new parenthesis matcher should be able to handle this situation 
pretty well.  A mismatched closing bracket (as in the [(()] situation 
you suggest in lines 1 and 2 below), terminates all open matches and 
matching starts fresh from the next paren.  Thus all the code until 
line 3 should match properly.  Line 3 will have extra closing 
parentheses since they should match things before the error and they 
will be highlighted in the error color.

-Scott


On Nov 6, 2003, at 3:22 PM, Jim Witte wrote:

>  For list-related administrative tasks:
>  http://list.cs.brown.edu/mailman/listinfo/plt-scheme
>
> 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*!!