Yield should be renamed call_block

[David A. Black-2]

Hi --

On Tue, 10 Jul 2007, Robert Dober wrote:

> On 7/9/07, James Edward Gray II <james@...> wrote:
>> On Jul 9, 2007, at 8:27 AM, John Joyce wrote:
> <snip>
>> > the '&' sigil is kind of scary. Reminds me of C. I'd be
>> > disappointed to see Ruby get more sigils.
>>
>> That's nothing new for Ruby.  It works today.  It's also needed.
> I am with you here the & makes code more readable for me.

And to me, unless you absolutely need it, it's line noise.  So I guess
we cancel each other out :-)  But I've given up on "readability" as a
criterion of anything.  It's too much like "intuitiveness" -- we've
all got our own :-)

I've always thought of the yield mechanism as one of the most
strikingly elegant and expressive things in Ruby.  (More subjective
judgment :-)  I'm actually very surprised to hear that it's likely to
disappear, or change considerably.

>> Without it, it wouldn't be possible to save a block into a variable
>> for later use.
> That is not true though
>
> def return_given_block
>  Proc.new
> end
> p = return_given_block { puts 42 }
> p.call

Interesting -- I didn't know that would happen.  However, I think
James's point was about using the block in a variable in the method
(e.g., for calling another method using the same block).


David

--
* Books:
   RAILS ROUTING (new! http://www.awprofessional.com/title/0321509242)
   RUBY FOR RAILS (http://www.manning.com/black)
* Ruby/Rails training
     & consulting:  Ruby Power and Light, LLC (http://www.rubypal.com)

[Robert Dober]

On 7/10/07, dblack@... <dblack@...> wrote:
> Hi --

>
> Interesting -- I didn't know that would happen.  However, I think
> James's point was about using the block in a variable in the method
> (e.g., for calling another method using the same block).
Am I missing something here?

def x
   y &Proc.new
end

that would be the equivalent to the preferred

def x &blk
   y &blk
end

Right?

Robert
--
I always knew that one day Smalltalk would replace Java.
I just didn't know it would be called Ruby
-- Kent Beck

[Robert Dober]

On 7/10/07, dblack@... <dblack@...> wrote:
Sorry for the second post :(

>
> I've always thought of the yield mechanism as one of the most
> strikingly elegant and expressive things in Ruby.  (More subjective
> judgment :-)  I'm actually very surprised to hear that it's likely to
> disappear, or change considerably.

I missed that point.
I completely agree with you, I *need* &blk -- with or without sigil ;)
-- and I need
yield, absolutely !!!
R.

[Bharat Ruparel-3]

> I've always thought of the yield mechanism as one of the most
> strikingly elegant and expressive things in Ruby.  (More subjective
> judgment :-)  I'm actually very surprised to hear that it's likely to
> disappear, or change considerably.
>

I think that Matz is on to something again!
The more I think of yeild as a method on an object, less it bothers me.
I have the mental crutch of being able to alias it anytime I wish.
Therefore, it does not seem like a big deal anymore whereas as a keyword
it is a big deal to me.  I guess the reason is that I am comfortable
dealing with different method names meaning the same thing in ruby,
e.g., map and collect.  I prefer map to collect.
I believe that as a rule, the language keywords should be as natural as
possible whereas library method names can and should be customizable.

Bharat

--
Posted via http://www.ruby-forum.com/.

[Robert Dober]

On 7/10/07, Bharat Ruparel <bruparel@...> wrote:

> > I've always thought of the yield mechanism as one of the most
> > strikingly elegant and expressive things in Ruby.  (More subjective
> > judgment :-)  I'm actually very surprised to hear that it's likely to
> > disappear, or change considerably.
> >
>
> I think that Matz is on to something again!
> The more I think of yeild as a method on an object, less it bothers me.
> I have the mental crutch of being able to alias it anytime I wish.
> Therefore, it does not seem like a big deal anymore whereas as a keyword
> it is a big deal to me.  I guess the reason is that I am comfortable
> dealing with different method names meaning the same thing in ruby,
> e.g., map and collect.  I prefer map to collect.
> I believe that as a rule, the language keywords should be as natural as
> possible whereas library method names can and should be customizable.
>
> Bharat
>

What you say is very sensible indeed, I do have a tiny little problem
with the approach though, it is restrictive.
You do not like yield? So why would you use it?
But why take it away from those who like to have it at their disposal?

Cheers
Robert

--
I always knew that one day Smalltalk would replace Java.
I just didn't know it would be called Ruby
-- Kent Beck

[David A. Black-2]

Hi --

On Tue, 10 Jul 2007, Bharat Ruparel wrote:

>> I've always thought of the yield mechanism as one of the most
>> strikingly elegant and expressive things in Ruby.  (More subjective
>> judgment :-)  I'm actually very surprised to hear that it's likely to
>> disappear, or change considerably.
>>
>
> I think that Matz is on to something again!
> The more I think of yeild as a method on an object, less it bothers me.

It would bother me if the object were one where the concept of
"yielding" didn't apply, like a Proc :-)

I always think of these things at least in part in relation to
teaching (or writing about) Ruby.  Explaining the concept of a method
yielding control to an anonymous function is actually quite easy to
explain, with a diagram or two.

Explaining block.yield, though, would be impossible.  What does it
yield?  Nothing.  What does it yield *to*?  It doesn't.  It's just a
word that used to have a different meaning and is now a synonym for
"call", even though "yield" and "call" have almost opposite semantics.

So... I'd rather not have it :-)  But I think the more interesting
thing is the question of what Matz is trying to address, namely the
business of being able to tell whether a method requires a block.  I
imagine that by 3.0 we'll have a wonderful and elegant way to do
exactly that.


David

--
* Books:
   RAILS ROUTING (new! http://www.awprofessional.com/title/0321509242)
   RUBY FOR RAILS (http://www.manning.com/black)
* Ruby/Rails training
     & consulting:  Ruby Power and Light, LLC (http://www.rubypal.com)

[Gary Wright-3]

On Jul 10, 2007, at 2:28 PM, dblack@... wrote:
> Explaining block.yield, though, would be impossible.  What does it
> yield?  Nothing.  What does it yield *to*?  It doesn't.  It's just a
> word that used to have a different meaning and is now a synonym for
> "call", even though "yield" and "call" have almost opposite semantics.

I think of 'yield' as short for 'yield control'.  The second definition
of 'yield' in the Oxford dictionary includes 'to relinquish possession
of something'.  The first definition is 'produce or provide'.

Ruby's 'yield' does both, it relinquishes control to the implicit block
and returns the reference that is produced by that block.

Gary Wright

[Yukihiro Matsumoto]

Hi,

In message "Re: Yield should be renamed call_block"
    on Tue, 10 Jul 2007 00:55:04 +0900, dblack@... writes:

|If this ends up happening, I would (reluctantly) suggest getting rid
|of "yield", and just use call.  b.yield, as others have pointed out,
|doesn't really work semantically: the function isn't yielding, it's
|being yielded *to*.

Since I am not a English speeker and I usually dont use that particlar
word, I feel like "yield" as rather like a symbol vaguly related to
passing valu to the blok.

Besides that, receivers often plays subjective roles for verbs (method
names), for example thread.kill or file.close, etc.

                                                        matz.

[Gregory Brown]

On 7/10/07, Yukihiro Matsumoto <matz@...> wrote:

> Hi,
>
> In message "Re: Yield should be renamed call_block"
>     on Tue, 10 Jul 2007 00:55:04 +0900, dblack@... writes:
>
> |If this ends up happening, I would (reluctantly) suggest getting rid
> |of "yield", and just use call.  b.yield, as others have pointed out,
> |doesn't really work semantically: the function isn't yielding, it's
> |being yielded *to*.
>
> Since I am not a English speeker and I usually dont use that particlar
> word, I feel like "yield" as rather like a symbol vaguly related to
> passing valu to the blok.
>
> Besides that, receivers often plays subjective roles for verbs (method
> names), for example thread.kill or file.close, etc.

That's true, but I shared the same confusion as David does when I was
playing with 1.9.
block.yield to me sounds like the opposite of block.call

In fact, my first instinct was to think this allowed currying for some reason.

like

block = lambda { |x,y| x + y + 3 }
block2 = block.yield(2)
block2.call(4) #=> 9

Of course, that imaginary syntax isn't a good idea either, but that's
what came to mind.

[Bharat Ruparel-3]

Thank you David and Gary, you both make a lot of sense.  David, I have
your book and found it extremely useful.  Reading it, I would almost
tell what you were going to say in the next paragraph and usually, you
would say it!  You are David Black right?  If not, you are just as good.
All I was saying when I posted this topic without much thinking is that
as Matz says that he likes to follow the principal of least surprise and
that Ruby does something right more often than otherwise is true by and
large.  Except in case of the yield keyword (for me).  I found that I
always have to do a mental translation and that slows me down.
As Gary points out, the dictionary meaning does fit in the context the
yeild keyword is used in English language.  It is just that I would have
picked something more direct.  It seems like being "direct" and avoiding
mental gymnastics are the key features that both DHH & Matz leverage
quite effectively in their work.  This one does seem indirect
intuitively.  I do not think that it is a language thing as I have
pretty much grown up studying the English language and have studied in
English for as long as I can remember.
Another thing that I want to reiterate is that ruby makes no secret of
providing many ways of saying the same thing with aliased methods which
is quite all right.  Aliasing keyword is not possible as Charles points
out above and should not be possible otherwise people will end up
inventing completely different languages within a language and that
would be defeating the purpose of having one common language.
Anyway, it has been very instructive listening to everyone with so much
Ruby experience.  One of the best things about Ruby and RoR communities
for that matter is that everyone is willing to share his/her knowledge
without being offensive.  That is why, I feel free in posting such "not
very well thoughtout" questions.
Regards everyone,
Bharat

--
Posted via http://www.ruby-forum.com/.

[David A. Black-2]

Hi --

On Wed, 11 Jul 2007, Yukihiro Matsumoto wrote:

> Hi,
>
> In message "Re: Yield should be renamed call_block"
>    on Tue, 10 Jul 2007 00:55:04 +0900, dblack@... writes:
>
> |If this ends up happening, I would (reluctantly) suggest getting rid
> |of "yield", and just use call.  b.yield, as others have pointed out,
> |doesn't really work semantically: the function isn't yielding, it's
> |being yielded *to*.
>
> Since I am not a English speeker and I usually dont use that particlar
> word, I feel like "yield" as rather like a symbol vaguly related to
> passing valu to the blok.

Vagueness would be OK, maybe, but the problem is bigger than that:
it's that "block.yield" just doesn't express what's happening.

> Besides that, receivers often plays subjective roles for verbs
> (method names), for example thread.kill or file.close, etc.

Those aren't the same, though:

   kill this thread
   close this file stream
   yield this function???   <= doesn't work, in terms of language

It's gets even more confusing with an argument:

   block.yield(x)

Are you yielding x, or the block?

Basically "yield" is a great name for a keyword (please don't remove
it ! :-) but very problematic as a "call" alias.  I'd advise fairly
strongly against using it that way.


David

--
* Books:
   RAILS ROUTING (new! http://www.awprofessional.com/title/0321509242)
   RUBY FOR RAILS (http://www.manning.com/black)
* Ruby/Rails training
     & consulting:  Ruby Power and Light, LLC (http://www.rubypal.com)

[ara.t.howard-2]

On Jul 10, 2007, at 3:33 PM, dblack@... wrote:

>> Since I am not a English speeker and I usually dont use that  
>> particlar
>> word, I feel like "yield" as rather like a symbol vaguly related to
>> passing valu to the blok.
>
> Vagueness would be OK, maybe, but the problem is bigger than that:
> it's that "block.yield" just doesn't express what's happening.

i'm with matz on this one

   block.yield

reads, to me, simple as

   'doing my own thing...'

   block.yield 'control to you'

or

   accum << block.yield

it's especially easy if you happen to think of blocks as a  
specialized form of co-routinues, which i happen to.


i have always disliked

   block.call

precisely because you are NOT doing that.  calling a function/method  
whatever implies a call stack and clean environment.  with blocks we  
actually invoke/yield to them in the particular way that makes them  
useful - which is to say that they execute within the closure in  
which they were defined.  in general i think it's highly damaging to  
align the terminology of methods and blocks, since the two operation  
in entirely different ways wrst closures and people generally have a  
very hard time with the concept of a real closure and all it's  
implications.

2cts.

regards.

-a
--
we can deny everything, except that we have the possibility of being  
better. simply reflect on that.
h.h. the 14th dalai lama

[Logan Capaldo]

While we are talking about the methodize-ation of keywords, any chance we
can get return "methodized"? (I mean callcc is a method, and raise is a
method, so it's not like call-stack manipulating methods don't already
exist...)

[Chad Perrin]

On Wed, Jul 11, 2007 at 07:36:34AM +0900, ara.t.howard wrote:

>
> i'm with matz on this one
>
>   block.yield
>
> reads, to me, simple as
>
>   'doing my own thing...'
>
>   block.yield 'control to you'

Speaking more generally . . .

The way I've always read the object.message syntax is that you're saying
something like "Hey, Object!  I want you to [yield]."  Substitute the
particular message you're sending for [yield] as necessary.

--
CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ]
print substr("Just another Perl hacker", 0, -2);

[David A. Black-2]

Hi --

On Wed, 11 Jul 2007, ara.t.howard wrote:

>
> On Jul 10, 2007, at 3:33 PM, dblack@... wrote:
>
>>> Since I am not a English speeker and I usually dont use that particlar
>>> word, I feel like "yield" as rather like a symbol vaguly related to
>>> passing valu to the blok.
>>
>> Vagueness would be OK, maybe, but the problem is bigger than that:
>> it's that "block.yield" just doesn't express what's happening.
>
> i'm with matz on this one
>
> block.yield
>
> reads, to me, simple as
>
> 'doing my own thing...'
>
> block.yield 'control to you'

But "yield" does not mean "take control".  It means relinquish
control.  That's why it makes sense as a control-flow directive --
control, independent of any specific object-messaging, switches upon
"yield" -- and not as a message being sent to an object.  That object
is not supposed to relinquish control, so it doesn't make sense to ask
it to.

And if you interpret it as more like "thread.kill" than like
"string.split" (i.e., telling the system to kill a thread, rather than
telling a string to split), then you're telling the system to yield a
block.  But the system doesn't yield blocks; it yields (relinquishes
control) *to* blocks.

I suspect that if we didn't have the 'yield' keyword and the process
of making a transition to having it be message-style, I don't think
"yield" would ever show up as a suggestion for a name for this method
(though of course an astonishing number of terms show up in the
various free-for-all method-name suggestion fests :-)

> or
>
> accum << block.yield

That still doesn't tell me what it means for a block to yield.  I
think I smiley-ly suggested:

   yield >> block

earlier, but I actually think that's much better than block.yield.
Make yield explicitly yield to a variable, if necessary, but don't
send the message "yield" to an object that has no intention of
yielding anything, nor any intention of being yielded.

> it's especially easy if you happen to think of blocks as a specialized form
> of co-routinues, which i happen to.

I do too; they're co-routines to which control is yielded.  They yield
control *back*, but that's another matter :-)


David

--
* Books:
   RAILS ROUTING (new! http://www.awprofessional.com/title/0321509242)
   RUBY FOR RAILS (http://www.manning.com/black)
* Ruby/Rails training
     & consulting:  Ruby Power and Light, LLC (http://www.rubypal.com)

[David A. Black-2]

Hi --

On Wed, 11 Jul 2007, Chad Perrin wrote:

> On Wed, Jul 11, 2007 at 07:36:34AM +0900, ara.t.howard wrote:
>>
>> i'm with matz on this one
>>
>>   block.yield
>>
>> reads, to me, simple as
>>
>>   'doing my own thing...'
>>
>>   block.yield 'control to you'
>
> Speaking more generally . . .
>
> The way I've always read the object.message syntax is that you're saying
> something like "Hey, Object!  I want you to [yield]."  Substitute the
> particular message you're sending for [yield] as necessary.

Exactly -- blocks don't yield, so let's not ask them to :-)


David

--
* Books:
   RAILS ROUTING (new! http://www.awprofessional.com/title/0321509242)
   RUBY FOR RAILS (http://www.manning.com/black)
* Ruby/Rails training
     & consulting:  Ruby Power and Light, LLC (http://www.rubypal.com)

[Chad Perrin]

On Wed, Jul 11, 2007 at 09:28:14AM +0900, dblack@... wrote:

>
> On Wed, 11 Jul 2007, Chad Perrin wrote:
> >On Wed, Jul 11, 2007 at 07:36:34AM +0900, ara.t.howard wrote:
> >>
> >>i'm with matz on this one
> >>
> >>  block.yield
> >>
> >>reads, to me, simple as
> >>
> >>  'doing my own thing...'
> >>
> >>  block.yield 'control to you'
> >
> >Speaking more generally . . .
> >
> >The way I've always read the object.message syntax is that you're saying
> >something like "Hey, Object!  I want you to [yield]."  Substitute the
> >particular message you're sending for [yield] as necessary.
>
> Exactly -- blocks don't yield, so let's not ask them to :-)

Is the word "accept" being used for anything?

--
CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ]
Isaac Asimov: "Part of the inhumanity of the computer is that, once it is
completely programmed and working smoothly, it is completely honest."

[David A. Black-2]

Hi --

On Wed, 11 Jul 2007, Chad Perrin wrote:

> On Wed, Jul 11, 2007 at 09:28:14AM +0900, dblack@... wrote:
>>
>> On Wed, 11 Jul 2007, Chad Perrin wrote:
>>> On Wed, Jul 11, 2007 at 07:36:34AM +0900, ara.t.howard wrote:
>>>>
>>>> i'm with matz on this one
>>>>
>>>>  block.yield
>>>>
>>>> reads, to me, simple as
>>>>
>>>>  'doing my own thing...'
>>>>
>>>>  block.yield 'control to you'
>>>
>>> Speaking more generally . . .
>>>
>>> The way I've always read the object.message syntax is that you're saying
>>> something like "Hey, Object!  I want you to [yield]."  Substitute the
>>> particular message you're sending for [yield] as necessary.
>>
>> Exactly -- blocks don't yield, so let's not ask them to :-)
>
> Is the word "accept" being used for anything?

$ ri Proc#accept
Nothing known about Proc#accept

Doesn't look like it :-)


David

--
* Books:
   RAILS ROUTING (new! http://www.awprofessional.com/title/0321509242)
   RUBY FOR RAILS (http://www.manning.com/black)
* Ruby/Rails training
     & consulting:  Ruby Power and Light, LLC (http://www.rubypal.com)

[Chad Perrin]

On Wed, Jul 11, 2007 at 09:37:56AM +0900, dblack@... wrote:
>
> On Wed, 11 Jul 2007, Chad Perrin wrote:
> >
> >Is the word "accept" being used for anything?
>
> $ ri Proc#accept
> Nothing known about Proc#accept
>
> Doesn't look like it :-)

It seems like words such as the following would be appropriate:

  accept
  receive
  request

I don't know about "call", though.  Maybe?

Maybe I'm not the guy to ask, though.

--
CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ]
Paul Graham: "Real ugliness is not harsh-looking syntax, but having to
build programs out of the wrong concepts."

[Yukihiro Matsumoto]

Hi,

In message "Re: Yield should be renamed call_block"
    on Wed, 11 Jul 2007 08:43:12 +0900, "Logan Capaldo" <logancapaldo@...> writes:

|While we are talking about the methodize-ation of keywords, any chance we
|can get return "methodized"? (I mean callcc is a method, and raise is a
|method, so it's not like call-stack manipulating methods don't already
|exist...)

I think we will lose great chance of optimization by making return,
break, etc. into methods.

                                                        matz.