Yield should be renamed call_block

[Bharat Ruparel-3]

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?

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

[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

On 7/9/07, Bharat Ruparel <bruparel@...> 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?
>
> --
> Posted via http://www.ruby-forum.com/.
>
>

[Simen Edvardsen]

On 7/9/07, Bharat Ruparel <bruparel@...> 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?

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


--
- Simen

[Simen Edvardsen]

On 7/9/07, Simen Edvardsen <toalett@...> wrote:

> On 7/9/07, Bharat Ruparel <bruparel@...> 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?
>
> > --
> > Posted via http://www.ruby-forum.com/.
> >
> >
>
>
> --
> - 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.

--
- Simen

[Yukihiro Matsumoto]

Hi,

In message "Re: Yield should be renamed call_block"
    on Mon, 9 Jul 2007 09:10:23 +0900, Bharat Ruparel <bruparel@...> 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.

[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@...> 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...))

John Joyce

[Chad Perrin]

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.

s/Intuivitely/Intuitively/

(as long as we're correcting stuff)

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

[Chad Perrin]

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

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

[Chad Perrin]

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

s/segway/segue/

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

--
CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ]
Baltasar Gracian: "A wise man gets more from his enemies than a fool from
his friends."

[Charles Oliver Nutter-2]

John Joyce 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

[Bertram Scharpf]

Hi,

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

Bertram


--
Bertram Scharpf
Stuttgart, Deutschland/Germany
http://www.bertram-scharpf.de

[David A. Black-2]

Hi --

On Mon, 9 Jul 2007, 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@...> 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?


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/9/07, SonOfLilit <sonoflilit@...> 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 :(


Cheers
Robert

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

[Yukihiro Matsumoto]

Hi,

In message "Re: Yield should be renamed call_block"
    on Mon, 9 Jul 2007 19:17:13 +0900, dblack@... 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.

[Martin DeMello]

On 7/9/07, Yukihiro Matsumoto <matz@...> 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

[Bertram Scharpf]

Hi,

Am Montag, 09. Jul 2007, 21:06:58 +0900 schrieb Yukihiro Matsumoto:
> [...] would go like this
>
>   def ntimes(n, &b)
>     n.times do
>       b.yield
>     end
>   end

  s/yield/call/

Bertram


--
Bertram Scharpf
Stuttgart, Deutschland/Germany
http://www.bertram-scharpf.de

[Robert Dober]

On 7/9/07, Bertram Scharpf <lists@...> wrote:

>
>   s/yield/call/
>
> Bertram

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

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

[John Joyce]

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

> Hi,
>
> In message "Re: Yield should be renamed call_block"
>     on Mon, 9 Jul 2007 19:17:13 +0900, dblack@... 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
>
>

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

[John Joyce]

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

> John Joyce 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 Joyce

[James Gray-7]

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

>
> On Jul 9, 2007, at 7:06 AM, Yukihiro Matsumoto wrote:
>
>> Hi,
>>
>> In message "Re: Yield should be renamed call_block"
>>     on Mon, 9 Jul 2007 19:17:13 +0900, dblack@... 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
>>
>>
> 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 Gray II