Hi,

I know you would not let me fall down! :-) I did know, that I could
use `&' in a argument list during method definition, but I had not
known that it can also be used during method invocation. Much to
learn yet, I think. :-)

If I did, I would not make that proposal, sorry :-(

But it is interesting! In a argument list it would convert a block to
a Proc instance, while during method invocation it converts a Proc
instance into a block! Nice, really :-)

BTW: I have silly used the term `block' for the `do ... end' and `{
... }' constructs. What would be the right term in Ruby?

On Sun, 25 Jul 1999, you wrote:
>Hi,
>

[...]

>        def each(blk=lambda)
>          ...
>        end
>
>to receive blocks as the normal argument.  By this way, you can supply
>the Proc as the argument to the method, which also works as iterator.

I have already found that trick. :-) So my code below was born.

>
>|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?
>
>That's desined so.  Use lambda/proc/Proc.new instead.  They work as
>you want, I guess.

Unfortunately not. Please have a look to my method `block' again. If I
would use `lambda' or family, it would be an error to NOT providing
`each' with a block or a Proc instance.

What I would like to have, perhaps, would be a kind of `lambda',
`proc' or `Proc#new' which would return `nil' if there was no block
instead of issuing an exception.

I have written `perhaps' because ...

>
>You can pass block as the special block argument like:
>
>	blk = proc{ |e| p e }
>	<xxx>.each(&blk)
>

That would be the solution. Well... almost. The only remaining thing,
that disturbes me a little bit it, that I (the programer) have to
know, whether that certain method would expect a block or a Proc
instance!

I.e. I would have to know, whether I have to call a method like:

	anyObject.anyMethod &blk
or
	anyObject.anyMethod blk

>BTW, by historical reason, the block treatment is tuned up for yield.
>The method using yield runs several times faster than one using Proc
>object.  That's one of the reasons why we can't avoid yield fully.

It is really a pitty, that Proc instances are not blocks! As block
seem to behave like Proc instance, is it not possible to clean-up
that difference? As blocks are faster than Proc instances, I would
propose, that `Proc#new' would create blocks instead of Proc
instances. Would that be possible?

[...]

>I think the block argument &block (in invoking method) is the right
>tool for you.  You can pass any Proc object as the block.
>
>	binary_handler = proc{ <...> }
>	text_handler = proc{ <...> }
>	:
>	handler = textfile(filename) ? text_handler : binary_handler
>	File::open filename, &handler

Yep! It is okay. But nevertheless it would be cool to treat Proc
instances and blocks the same way!

>
>                                                matz.

\cle