From: Wayne Kelly <w.kelly@...>
Date: 2006-03-09T10:45:00+09:00
Subject: break semantics from lambdas and methods

Hi All,

I'm having trouble understanding the logic behind the semantics
of the break construct, specifically when used in lamdbas and methods.

The following example illustrates what to me appears to be inconsistent
logic. Is this behaviour intended? If so, can anyone shed any light on
the logic behind it.

My issue is with cases 4 and 5.
- Shouldn't case 4 behave the same as either case 1 or case 2?
- As I understand it, lambdas are meant to behave more like methods
   rather than blocks, but it case 5, methods are behaving more like
   blocks than are lambdas, and methods behave like blocks only when
   called rather than yielded.

Cheers, Wayne.

-----------------------------------------------------------------

def myiterator1(list)
     for i in list
         yield(i)
     end
end

def myiterator2(list, proc)
     for i in list
         proc.call(i)
     end
end

def bar(x)
     puts x; break; puts 'after'
end

method = Kernel.method(:bar)

lambda = Kernel.lambda { |x| puts x; break; puts 'after' }


# case 1: break causes iterator to exit (as expected)
myiterator1(1..10) { |x| puts x; break; puts 'after' }

# case 2: LocalJumpError - break from proc-closure (ok)
myiterator1(1..10, &lambda)

# case 3: LocalJumpError - break from proc-closure (ok)
myiterator1(1..10, &method)

# case 4: break causes block to exit but not iterator (why???)
myiterator2(1..10, lambda)

# case 5: break causes iterator to exit (just like a block in case 1)
myiterator2(1..10, method)