From: Markus <markus@...>
Date: 2004-10-09T04:37:23+09:00
Subject: Re: quality of error messages

     The problem (as I responded before) is that this would complain
about almost everyone's code since (*smile* I presume because you are
all unwashed heathens, but there, may be other reasons) people tend to
follow the "match pairs" rule instead of tucking the "end"s in as the
last item of the block.

     The rule as everyone states it (including here) would object to the
ends being at the same indentation as the "containing" structure, which
is where pair-matchers put them.  People _say_ that they indent
according to salience, but in fact they pair match.

     So, in summary, I suspect that I would be happy with this rule but
almost everyone else would be happier with the modified (< vs. <=)
version I suggested earlier on this thread, which would allow:

      starting thing
           guts
           intestines
           gizzards
      end 

instead of the salient form:


      starting thing
           guts
           intestines
           gizzards
           end 

which would be expected by the rule as stated.

     -- Markus


On Fri, 2004-10-08 at 12:26, Charles Hixson wrote:
> 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.
> 
> 
>