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?
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
···
On 7/9/07, Bharat Ruparel <bruparel@mercury.com> wrote:
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?
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?
···
On 7/9/07, Bharat Ruparel <bruparel@mercury.com> wrote:
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.
···
In message "Re: Yield should be renamed call_block" on Mon, 9 Jul 2007 09:10:23 +0900, Bharat Ruparel <bruparel@mercury.com> writes:
"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.
···
On 7/9/07, Simen Edvardsen <toalett@gmail.com> wrote:
On 7/9/07, Bharat Ruparel <bruparel@mercury.com> wrote:
> 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?
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 Joyce
···
On Jul 8, 2007, at 7:58 PM, Yukihiro Matsumoto wrote:
Hi,
In message "Re: Yield should be renamed call_block" > on Mon, 9 Jul 2007 09:10:23 +0900, Bharat Ruparel > <bruparel@mercury.com> 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.
That sounds pretty good -- and more consistent across the language, too.
···
On Mon, Jul 09, 2007 at 09:58:23AM +0900, Yukihiro Matsumoto wrote:
Hi,
In message "Re: Yield should be renamed call_block" > on Mon, 9 Jul 2007 09:10:23 +0900, Bharat Ruparel <bruparel@mercury.com> 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.
--
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."
In message "Re: Yield should be renamed call_block" > on Mon, 9 Jul 2007 09:10:23 +0900, Bharat Ruparel <bruparel@mercury.com> 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.
I'm curious what the rationale is for that. Also, will the block
syntax be removed, in favor of Proc arguments?
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
···
On 7/9/07, SonOfLilit <sonoflilit@gmail.com> wrote:
--
I always knew that one day Smalltalk would replace Java.
I just didn't know it would be called Ruby
-- Kent Beck
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.
>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.
This is similar to how we implement blocks in JRuby. All methods receive a block, but it may be a "null block" that raises when yielded to and returns false for "given?". But there's always some kind of block regardless, and other than the syntactic sugar of yield versus call, it's largely the same code.
- Charlie
···
In message "Re: Yield should be renamed call_block" > on Mon, 9 Jul 2007 09:10:23 +0900, Bharat Ruparel <bruparel@mercury.com> writes:
On Mon, Jul 09, 2007 at 09:32:26AM +0900, Simen Edvardsen wrote:
>
>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?!
"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.
--
CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ]
Dr. Ron Paul: "Liberty has meaning only if we still believe in it when
terrible things happen and a false government security blanket beckons."
. . . unless those scooter things are what you had in mind in the first
place.
···
On Mon, Jul 09, 2007 at 12:43:57PM +0900, John Joyce wrote:
On Jul 8, 2007, at 7:58 PM, Yukihiro Matsumoto wrote:
>Hi,
>
>In message "Re: Yield should be renamed call_block" > > on Mon, 9 Jul 2007 09:10:23 +0900, Bharat Ruparel > ><bruparel@mercury.com> 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.
>
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...))
--
CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ]
Baltasar Gracian: "A wise man gets more from his enemies than a fool from
his friends."
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.
Am Montag, 09. Jul 2007, 14:39:15 +0900 schrieb Chad Perrin:
On Mon, Jul 09, 2007 at 09:58:23AM +0900, Yukihiro Matsumoto wrote:
> In message "Re: Yield should be renamed call_block" > > on Mon, 9 Jul 2007 09:10:23 +0900, Bharat Ruparel <bruparel@mercury.com> 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.
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!
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.
···
In message "Re: Yield should be renamed call_block" on Mon, 9 Jul 2007 19:17:13 +0900, dblack@wobblini.net writes:
1. I have to plead ignorance. I do not know the language history very
well. What is CLU?
CLU is a programming language designed in MIT back in 70s. CLU has a
functionality called an iterator which fundamentally equals to a
method call with a block in Ruby, except that a iterator must be
called within a for statement. For more information, Google is your
friend.
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.
I think incompatibility can be introduced time to time in the
evolution of languages. I try not to make them too often though.
matz.
···
In message "Re: Yield should be renamed call_block" on Mon, 9 Jul 2007 23:59:35 +0900, Bharat Ruparel <bruparel@mercury.com> writes:
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.
···
On 7/9/07, Bharat Ruparel <bruparel@mercury.com> wrote:
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.
