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

On Sat, 2004-10-09 at 02:11, Brian Candler wrote:
> On Sat, Oct 09, 2004 at 04:37:23AM +0900, Markus wrote:
> >      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.
> 
> Yeah, I know. That was something I glossed over, because I didn't want to
> think it through :-)
> 
> I think that: if a line begins with 'end', then you process it (reduce the
> nesting level) *before* checking whether the line's indentation level
> matches what you expect. And if there's more than one, I suppose you have to
> process them all, in case anyone writes something silly like
> 
>    class Foo; def bar; begin
>          puts "hello"
>    end; end; end

     Looking ahead adds whole gobs of complexity, and may not help as
much as you think (just my intuition, but I've been led down paths that
looked a lot like that before).

     There is a simpler (and more general) solution in my opinion. 
Don't try to codify what people do, because they don't all do the same
thing, they aren't always consistent, and it is fairly complicated to
define exactly in most cases (salience/pair-matching hybrids).

     Instead, try to capture what they DON'T do, and store the location
to use in the message if there turns out to be a problem.  What don't
they do?  

      * They don't 'exdent' beyond the indentation of the line that
        started the present construct, except for comments & here docs,
        etc. which are already distinguished by the compiler.
      * They don't start a nested construct at the same indentation
        level of the present construct.

I suspect that this would be dirt simple to implement, especially
compared to anything that required lookahead.

> Another construct which may cause difficulty is
> 
> case foo
> when /bar/
>   ...
> else
>   ...
> end
> 
> since I've seen other ways of laying this out.

     All the ways I've seen would work fine with the simple "oddness"
test above.  They may not be the way I'd do it, but they weren't 'odd'.

-- Markus