Yukihiro Matsumoto wrote: >Hi, > >In message "Re: quality of error messages" > on Fri, 8 Oct 2004 12:58:26 +0900, Jamis Buck <jgb3 / email.byu.edu> writes: > >|> We can. But how we check for missing/broken def/end pairs, more than >|> just syntax error? > >|I believe what is being asked for is more than just a "syntax error" >|message. If the error could be more specific, like "missing 'end' on >|line x", it would greatly increase the usefulness of the -c option. > >I know what he wants. I am not refusing his idea. The point is I'm >not yet sure how to detect missing pairs. > > matz. > The best suggestion that i've seen was from B.Candler / pobox.com (above). I'll quote a bit: <<EOM I think that you don't have to enforce any particular indentation style or amount of space on each line - only that it is consistent between begin and end. If we define the 'nesting depth' as the number of module / class / def / do / if sections we are within (i.e. the number of matching 'end's we expect to see), then: - at the start of each line, count the number of spaces. Ignore lines which consist entirely of whitespace. R1: if the nesting depth is the same as the previous line, then raise a warning if the number of spaces is not the same as the previous line R2: if the nesting depth is greater than the previous line, then remember the indentation of this line associated with this nesting depth (e.g. on a stack) R3: if the nesting depth is less than the previous line, then raise a warning if the number of spaces is not the same as the last line with the same nesting depth EOM He goes on to explain further, and give examples. I don't know how difficult this would be to implement, but it looks like a good answer -- if feasible. I don't think that this should be a syntax rule, but purely used as an (optional?) heuristic for error detection. I.e., take it as a description of how people DO tend to write code rather than a rule of how they MUST.