From: Charles Hixson <charleshixsn@...>
Date: 2004-10-09T04:26:10+09:00
Subject: Re: quality of error messages

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.