Yield should be renamed call_block

[Bharat Ruparel]

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?

 

[SonOfLilit]

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

 

[Simen Edvardsen]

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?

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?

 

[Simen Edvardsen]

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

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?

"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.

 

[Chad Perrin]

"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.

s/Intuivitely/Intuitively/

(as long as we're correcting stuff)

 

[Chad Perrin]

Hi,

In message "Re: Yield should be renamed call_block"

|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.

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

 

[Bertram Scharpf]

Hi,

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

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

 

[Robert Dober]

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


Cheers
Robert

 

[Bharat Ruparel]

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.

Hello Matz,
Before I say anything, I want to congratulate you for designing
something as elegant as Ruby. I think that DHH, you, and a whole lot of
other people have started something that can fundamentally change the
way IT functions IF handled with a bit of foresight, and off course,
luck. Thanks to you and DHH, programming is fun again.

Here is a question and feedback based on your responses and everyone
else's (equally appreciated):

1. I have to plead ignorance. I do not know the language history very
well. What is CLU?

2. I think that moving "yeild" to a method call is a great idea. That
way it can be freely aliased as and when needed. Why are you saying
that it will be done that far out (3.0?). Are you concerned about
"breaking" existing code? Educate me.

Thanks.

Bharat

 

[Simen Edvardsen]

2. I think that moving "yeild" to a method call is a great idea. That
way it can be freely aliased as and when needed. Why are you saying
that it will be done that far out (3.0?). Are you concerned about
"breaking" existing code? Educate me.

Thanks.

Bharat

I think that in general, stuff that relies on implementation details
such as yield (you must lookup the block in the current scope) is a
language feature, and should be treated as such. The alternative would
be if Ruby provided a cross-platform interface to the interpreter, but
I don't see that happening anytime soon.

Also, aliasing "yield" would lead to confusion. I think it's good to
enforce consistency in this case.

 

[Bharat Ruparel]

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

 

[Robert Dober]

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

 

[dblack]

Hi --

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]

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

 

[Bharat Ruparel]

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