From: dblack@...
Date: 2003-04-28T19:30:01+09:00
Subject: Re: block.call vs. yield

Hi --

On Mon, 28 Apr 2003, Gavin Sinclair wrote:

> The same argument applies to Proc#call.
>
>   p = proc { |x| x + 3 }
>   p.call(2)   # -> 5
>
> Really, a more accurate name would be
>
>   p.be_called(2)
>
> In David's language:
>
>   "blk.call" suggests that the block is performing an action described
>   as 'call'ing, which I don't think it is.

There's some precedent for receivers as "direct objects" of the verbs
in their methods (e.g., Array#pack/flatten/sort,
String#crypt/capitalize/center, etc.).  So in that one can "call a
Proc", one can imagine Proc#call.  But one does not "yield a Proc".
If anything, one yields parameters *to* a Proc.

> The two methods following are functionally equivalent.
>
>   def foo1(n, &block)
>     block.call(n+1)
>   end
>
>   def foo2(n)
>     yield n+1
>   end
>
> They are effectively the same, and they both make sense.  But what is
> that "yield" *really*?  It's like a method call with an implicit
> receiver.  The receiver is the block passed to the method call.
>
> If we are happy with "yield" (the keyword) being an implicit method
> call, why can't we allow it to be an explicit method call, in which it
> does the same thing?

If it's an implicit method call (which isn't how I would describe it,
but anyway), the phantom receiver would be, I think, the current
method.  I.e., it's more like: I (the method) am going to yield
control to a block, rather than: I (the block) am going to yield, or
be yielded.

This isn't an exact match with other constructs -- but it isn't
supposed to be.  That's why yield is so cool :-)  It's also another
reason I like the idea of isolating the 'yield' keyword.

> The keyword "yield" was probably borrowed from another language, but
> it helps to consider what it really means, which is "produce".  This
> makes sense as a keyword because it is producing a value, or list of
> values, to be consumed by an anonymous block.

I think what it really means is "yield" -- i.e., yield control, at
this point in the program.

> Therefore, "yield" is a special case issue of "giving way" (another

Yeah, that :-)

> meaning of yield) to the parent method, temporarily.  It really is the

(Actually to the block, *from* the method.)

> perfect name for what it does.  But it's not the perfect name to
> describe mvalues, avalues and parameters.  That's where David et al
> have a good point.

The question then becomes: why press it into service for that?
Electrons are cheap :-)


David

-- 
David Alan Black
home: dblack@superlink.net
work: blackdav@shu.edu
Web:  http://pirate.shu.edu/~blackdav