On Sun, 8 Sep 2002 14:03:05 +0900, Hal E. Fulton wrote: > One idea I've wondered about is making the parser "smart" enough > to (at least) speculate about where an error *really* happened, > based on indentation. [Note: In my examples I'm going to use 'n+' to indicate that the parser has pushed a block open on a stack for line 'n' and 'n-' to pop it off the stack because it's closed at line 'n'.] Granted, I'm not a parser writer or a language designer, but why not have the parser backtrack to the last matching block open? I mean, in some cases, you'll give the wrong error anyway, but in the general case: 1 def fun 2 if foo then 3 end The parser would push the block open/close locations as 1+:2+:3-. The assumption should be that the error is at the second push (2+), because in reality, the programmer isn't likely to have been stupid enough to not close the function definition, but the "if" statement. The error would be reported, therefore, at line two, not line one. As I understand it now, the parser assumes that it is the first push (line one) that is at error. In a more complex case, as: A B 1 begin | begin 2 if foo then | if foo then 3 end | end 4 | 5 begin | begin 6 | do 7 do | 8 begin | begin 9 end | end 10 end | end 11 end | end The parser would push that as 1+:2+:3-:5+:7+:8+:9-:10-:11-. Depending on how the tracking of "last block open" is done, the parser would report either line five or eight as the offending line; line five is obviously correct in case A, eight is obviously correct in case B. In either case, reporting either five or eight would be more correct than reporting line one ... right? I'd personally prefer in most cases that line five be reported, even in case B, but line eight may to be more consistent. Am I completely off-base here? -austin -- Austin Ziegler, austin / halostatue.ca on 2002.09.08 at 01.26.25