h.fulton / att.net writes:

> But if it were optional: 1. Wouldn't that reduce its
> usefulness?

No more than (say) the -w flag - if someone wanted the additional
checking they could enable it.

> 2. And wouldn't it complicate the parser
> rather than simplifying it?

I suspect it wouldn't be a major change - I think it would all be
handled at the yacc level:


        | kFOR block_var kIN {cond_nest++;} expr do {cond_nest--;}
	  compstmt
	  kEND

would become

        | kFOR block_var kIN {cond_nest++;} expr do {cond_nest--;}
	  compstmt
	  for_end

for_end:  kEND kFOR
       |  kEND


But not having tried it, I'm sure it's more complicated than that
(says the master of the shift/reduce conflict ;-)

There's an alternative that might be worth investigating. When Ruby
detects the parse error, could it output more context?

    class Dave
      def fred
        a = 1
    end

    d = Dave.new

=>

    5: parse error
       -  defining class Dave


and

      class Dave
        def fred
          a = 1
        def bert
        end
      end

=>
    4: nested method definition
       - defining method fred in class Dave