Hi,

some days before, someone has shown following example in Smalltalk:

	:
	do: aBlock
	   list1 do: aBlock
	   list2 do: aBlock
	:

The closest I can come in Ruby is something like:

	:
	def each(&aBlock)
	   @list1.each{ |e| aBlock.call(e) }
	   @list2.each{ |e| aBlock.call(e) }
	end
	:

Is there something I have overseen? Is that the only way to come as
close as possible to the Smalltalk solution?

Let me spin some ideas, okay?

I don't like the decision to separate Proc instances from, let me
name it here, blocks. Here a `block' will mean code, enclosed by a
`do ... end' resp. `{ ... }' construct.

I don't know, why following is not possible directly:

	blk1 = { |e| p(e) }
or
	blk1 = do |e| p(e) end

perhaps difficult to parse, matz? But there are two methods,
which support us to convert a block into a Proc instance: `lamdba'
and `proc'. So at least following become possible:

	blk1 = proc{ |e| p(e) }
or
	blk1 = proc do |e| p(e); end

So I can live with it, although I don't like it very much, to speake
the truth. The next thing, I like first, is `yield' (and, of course,
`rb_yield' too). But now, I ask myself, if `yield' is really
necessary? Could we avoid its usage? If I have not overseen anything
(which should be probable, if I remember my ideas before ;-), I think
it is easy to avoid! Instead of defining methods like this:

	:
	def each
	   for i in 1..@len
	      yield @field[i]
	   end
	end
	:

we could easily define it like that:

	:
	def each(aBlock=nil)
	   aBlock = proc if not aBlock and iterator?
	   for i in 1..@len
	      aBlock.call(@field[i])    # or aBlock[@field[i]] ;-)
	   end
	end
	:

Okay we would have on check more, but we would have the
advantage, that the method could get both, a Proc instance or a
block for execution. So it would be possible to do both:

	:
	<xxx>.each{ |e| p e }
	:
and
	:
	blk = proc{ |e| p e }
	:
	<xxx>.each blk
	:

wouldn't that be nice? Or is there any problem with these, that I
have not seen until yet?

If not, I would propose, that all built-in methods using `yield'
should be rewritten to the scheme shown above. Furthermore it should
be recommended to avoid `yield' in new implementations. But we should
not remove it, to be upwards compatible.

Then we could rewrite the Smalltalk example above as:

	:
	def each(aBlock=nil)
	   aBlock = proc if not aBlock and iterator?
	   @list1.each aBlock
	   @list2.each aBlock
	end
	:

Unfortunately the following seems not to be possible at the moment:

	:
	def block; (iterator?) ? proc : nil end

	def each(aBlock=block)
	   @list1.each aBlock
	   @list2.each aBlock
	end
	:

The method `block' will not be executed in the context of `each'! Is
that designed so? If not, would it make sense to change that? The
problem for `block' is, that it cannot use `iterator?' to
determine, whether there follows a block after call of `each' or not.

Please don't get me wrong, but I propose these not to write the
Smalltalk example more elegant. That was only the starting point! But
at the end here I think it would be very comfortable to have these
possibilites.

We could not only decide at compiling time, what kind of block using
to iterate, but we could also decide it on runtime. We would be
able to do the following for example:

	:
	binary_handler = proc{ <...> }
	text_handler = proc{ <...> }
	:
	handler = textfile(filename) ? text_handler : binary_handler
	File::open filename, handler
	:

Let me stress it once more: We would not only be able to iterate
using a block, but also using a Proc instance. IMO, it would make
Ruby more flexible. Furthermore it would bring block and Proc
instances more close to each other.

What do you think about?

Happy discussing,
Cle