Yield should be renamed call_block

Ruby
1

One of the virtues of the Ruby language that is touted by just about
everyone including the language designer Matz is that it is supposedly
very intuitive, follows principle of least surprise, duck typing and on
and on.
I find it fascinating and quite a bit true. However, I have to always
mentally translate the keyword “yeild” to mean “call_block”. I find
that it is the biggest distraction that I have when I am trying to
figure out what and how a a method with a block and calling code
interact. I can understand all that baggage such as “lambda” function
name from Lisp and the wonderful “$” variables that came from Perl, but
where did the keyword yeild come from? And why has not anyone aske Matz
to consider changing it to infinitely more obvious “call_block”? It it
that big a deal? In an open source language?

2

I find that “yield” describes what the method does even better than
“call_block”.

Besides, there is a principle in ruby’s design of having the most used
methods be shorter.

It’s important because thinking “this function then yields” is far
more consise than thinking “this function then calls call_block”.

POLS, btw, is defined as “POLS to Matz”, and there is much emphasis on
that.

Aur

3

On 7/9/07, Bharat R. [email protected] wrote:

where did the keyword yeild come from?
Intuivitely, a function yields its hold of the Vm/interpreter to its
caller. “Yield” is also used in some cooperative-threading
implementations, in which a thread yields control to the scheduler. I
don’t think the name is unintuitive at all. Besides, keywords should
be short, conscise, and why in the name of the Language Designer gods
should there be an underscore in a keyword?!

And why has not anyone aske Matz

to consider changing it to infinitely more obvious “call_block”? It it
that big a deal? In an open source language?

No, it’s not. You’re free to change the language so that “yield”
becomes “call_block” and release your own version. I don’t think it
requires much tweaking. But I guess you’ll be the only user, so why
bother?

4

On 7/9/07, Simen E. [email protected] wrote:

name from Lisp and the wonderful “$” variables that came from Perl, but
to consider changing it to infinitely more obvious “call_block”? It it

–

  • Simen

“Intuivitely, a function yields its hold of the Vm/interpreter to its
caller.” should be “Intuivitely, a function yields its hold of the
Vm/interpreter to its
block”, of course.

5

On Jul 8, 2007, at 7:58 PM, Yukihiro M. wrote:

The “yield” keyword is used for this purpose from the ages of
languages for example in CLU. So if you learn the history and the
culture, you will find less problem.

I am not going to rename it. But in far future (3.0? maybe), the
keyword will be removed from the language, and you will access blocks
via block arguments of methods.

          matz.

to the OP, Of course with your won individual modules/libraries
loaded/required, you can alias yield to be whatever isn’t already
taken by something else. Ideas for aliases: yield_to, call_block,
step_out, segway, divert, fork, short_fork, lunch_break, junk_time,
call_junk, goto ((hehehe…))

John J.

6

On Mon, Jul 09, 2007 at 09:32:26AM +0900, Simen E. wrote:

Vm/interpreter to its
block", of course.

s/Intuivitely/Intuitively/

(as long as we’re correcting stuff)

7

Hi,

In message “Re: Yield should be renamed call_block”
on Mon, 9 Jul 2007 09:10:23 +0900, Bharat R.
[email protected] writes:

|I find it fascinating and quite a bit true. However, I have to always
|mentally translate the keyword “yeild” to mean “call_block”.

The “yield” keyword is used for this purpose from the ages of
languages for example in CLU. So if you learn the history and the
culture, you will find less problem.

I am not going to rename it. But in far future (3.0? maybe), the
keyword will be removed from the language, and you will access blocks
via block arguments of methods.

          matz.
8

On Mon, Jul 09, 2007 at 09:58:23AM +0900, Yukihiro M. wrote:

culture, you will find less problem.

I am not going to rename it. But in far future (3.0? maybe), the
keyword will be removed from the language, and you will access blocks
via block arguments of methods.

That sounds pretty good – and more consistent across the language, too.

9

On Mon, Jul 09, 2007 at 12:43:57PM +0900, John J. wrote:

always
matz.

to the OP, Of course with your won individual modules/libraries
loaded/required, you can alias yield to be whatever isn’t already
taken by something else. Ideas for aliases: yield_to, call_block,
step_out, segway, divert, fork, short_fork, lunch_break, junk_time,
call_junk, goto ((hehehe…))

s/segway/segue/

. . . unless those scooter things are what you had in mind in the first
place.

10

Hi,

Am Montag, 09. Jul 2007, 14:39:15 +0900 schrieb Chad P.:

I am not going to rename it. But in far future (3.0? maybe), the
keyword will be removed from the language, and you will access blocks
via block arguments of methods.

That sounds pretty good – and more consistent across the language, too.

It would mess up my whole code when I had to mention the bock
parameter every time it’s obvious there is one.

None of my methods is longer than 40 lines and this is a
habit I rely on every day. Pleeeease don’t remove the yield
mechanism!

Bertram

11

John J. wrote:

to the OP, Of course with your won individual modules/libraries
loaded/required, you can alias yield to be whatever isn’t already taken
by something else. Ideas for aliases: yield_to, call_block, step_out,
segway, divert, fork, short_fork, lunch_break, junk_time, call_junk,
goto ((hehehe…))

yield is a keyword. It can’t be renamed or aliased.

  • Charlie
12

Hi –

On Mon, 9 Jul 2007, Yukihiro M. wrote:

culture, you will find less problem.

I am not going to rename it. But in far future (3.0? maybe), the
keyword will be removed from the language, and you will access blocks
via block arguments of methods.

I’m curious what the rationale is for that. Also, will the block
syntax be removed, in favor of Proc arguments?

David

13

On 7/9/07, SonOfLilit [email protected] wrote:

I find that “yield” describes what the method does even better than
“call_block”.

Besides, there is a principle in ruby’s design of having the most used
methods be shorter.

It’s important because thinking “this function then yields” is far
more consise than thinking “this function then calls call_block”.

Agree 100%

POLS, btw, is defined as “POLS to Matz”, and there is much emphasis on that.
Disagree a little bit, I have seen Matz telling so but I believe there
was a smiley attached.
Maybe one can say that Matz’ POLS is slightly more important than the
community’s POLS which is difficult to determine sometimes.

Why am I saying this? I have seen the “POLS is Matz’ POLS” frequently
recently and I think the “real” POLS is indeed a great asset of Ruby
even or because it is so difficult to determine. It would be a pity to
lose this attitude.

It is of course clear that POLS for everyone is impossible :frowning:

Cheers
Robert

14

On 7/9/07, Yukihiro M. [email protected] wrote:

def ntimes(n, &b)
n.times do
b.yield
end
end

It reads wrong, now, though - the block isn’t yielding, the current
method is yielding to the block. #run might be a better method name.

martin

15

Hi,

In message “Re: Yield should be renamed call_block”
on Mon, 9 Jul 2007 19:17:13 +0900, [email protected] writes:

|> I am not going to rename it. But in far future (3.0? maybe), the
|> keyword will be removed from the language, and you will access blocks
|> via block arguments of methods.
|
|I’m curious what the rationale is for that. Also, will the block
|syntax be removed, in favor of Proc arguments?

The code

def ntimes(n)
n.times do
yield
end
end

would go like this

def ntimes(n, &b)
n.times do
b.yield
end
end

Rationals are:

  • you can detect methods that don’t take blocks, that
    currently ignored silently.
  • we can make yield sementics bit simpler.

The former is more prefereable.

          matz.
16

Hi,

Am Montag, 09. Jul 2007, 21:06:58 +0900 schrieb Yukihiro M.:

[…] would go like this

def ntimes(n, &b)
n.times do
b.yield
end
end

s/yield/call/

Bertram

17

On 7/9/07, Bertram S. [email protected] wrote:

s/yield/call/

Bertram

I am with Bertram here, #call is describing what is done here.

Robert

18

On Jul 9, 2007, at 7:06 AM, Yukihiro M. wrote:

|I’m curious what the rationale is for that. Also, will the block
would go like this

def ntimes(n, &b)
n.times do
b.yield
end
end

the ‘&’ sigil is kind of scary. Reminds me of C. I’d be disappointed
to see Ruby get more sigils.

19

On Jul 9, 2007, at 3:29 AM, Charles Oliver N. wrote:

John J. wrote:

to the OP, Of course with your won individual modules/libraries
loaded/required, you can alias yield to be whatever isn’t already
taken by something else. Ideas for aliases: yield_to, call_block,
step_out, segway, divert, fork, short_fork, lunch_break,
junk_time, call_junk, goto ((hehehe…))

yield is a keyword. It can’t be renamed or aliased.

There is always (usually) a way to wrap something in a method. You
can always make something def

John J.

20

On Jul 9, 2007, at 8:27 AM, John J. wrote:

blocks
end

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.
Without it, it wouldn’t be possible to save a block into a variable
for later use.

James Edward G. II