Yield should be renamed call_block

[Simen Edvardsen]

On 7/9/07, John Joyce <dangerwillrobinsondanger@...> wrote:
> the '&' sigil is kind of scary. Reminds me of C. I'd be disappointed
> to see Ruby get more sigils.
>
>
>

What are you talking about? The &-sigil in the argument list isn't a
proposed change, it's there already, so Ruby wouldn't be getting any
more sigils.

As for the aliasing yield-thing, it can't be done in Ruby, because it
depends on the local scope (maybe with hacks such as
Binding.of_caller, I'm not sure) . You'd need to inspect the stack,
which can't be done in Ruby and would rely on implementation details
in C. It just isn't worth it.

--
- Simen

[James Gray-7]

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

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

I believe this is one of the exceptions.  That's exactly why it is a  
keyword.

Give it a shot.

James Edward Gray II

[Rob Biedenharn-2]

On Jul 9, 2007, at 9: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 already part of the language.  You can use it right now to  
capture the block associated to a method as a Proc that you can  
manipulate.  Using &block you'd test block.nil? in the same way that  
you'd use block_given? when deciding to yield.  If you change the  
above code to be b.call, it works right now.

-Rob

Rob Biedenharn http://agileconsultingllc.com
Rob@...

[Yukihiro Matsumoto]

Hi,

In message "Re: Yield should be renamed call_block"
    on Mon, 9 Jul 2007 22:14:01 +0900, Bertram Scharpf <lists@...> writes:

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

You can.  They are mere aliases.

                                                        matz.

[Bharat Ruparel-3]

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

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

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

[Yukihiro Matsumoto]

Hi,

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

[Simen Edvardsen]

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

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.

--
- Simen

[David A. Black-2]

Hi --

On Mon, 9 Jul 2007, Simen Edvardsen wrote:

> On 7/9/07, John Joyce <dangerwillrobinsondanger@...> wrote:
>> the '&' sigil is kind of scary. Reminds me of C. I'd be disappointed
>> to see Ruby get more sigils.
>>
>>
>>
>
> What are you talking about? The &-sigil in the argument list isn't a
> proposed change, it's there already, so Ruby wouldn't be getting any
> more sigils.

I think he's talking about the fact that this:

   def x
     yield
   end

would no longer be possible (as I understand it).  So, in practice,
more Ruby code would have more & characters.


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

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*.  Maybe:

   yield >> b

or something.

The point about detecting blocks is interesting, though if a block is
still optional, you might end up testing at the calling end and in the
method, which seems like a lot of testing.  Or is there another
permutation for required block vs. optional 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)

[Charles Oliver Nutter-2]

James Edward Gray II wrote:
> On Jul 9, 2007, at 8:29 AM, John Joyce wrote:
>> There is always (usually) a way to wrap something in a method. You can
>> always make something def
>
> I believe this is one of the exceptions.  That's exactly why it is a
> keyword.
>
> Give it a shot.

Yes, I should have been more clear.

yield is a keyword whose function depends on having access to the
current call frame. Since any method you might define and call would
execute in a new call frame, there's no way to provide a method that
does what yield does. This is why if you ever want to pass a given block
to another method, you must capture it in a block argument, and also why
yielding to a block is much faster than calling a proc (since there's
less overhead in yielding than in calling a free-standing proc).

- Charlie

[Rob Biedenharn-2]

On Jul 9, 2007, at 11:43 AM, Yukihiro Matsumoto wrote:

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

> matz.

Since I learned CLU when I was at MIT, I'll help you out a bit here.

http://www.lcs.mit.edu/publications/pubs/pdf/MIT-LCS-TR-561.pdf

There is a lot of syntactic sugar in CLU also, although it isn't quite
as general in some places as in Ruby. CLU had three types of
abstraction: procedural, data, and iteration which were wrapped up in
a "cluster" (from which the language name comes).

Unfortunately, the courses that used to use CLU, started using
Java some years ago. ;-(

-Rob

Rob Biedenharn http://agileconsultingllc.com
Rob@...

[Florian Gross]

> This is why if you ever want to pass a given block
> to another method, you must capture it in a block argument, and also why
> yielding to a block is much faster than calling a proc (since there's
> less overhead in yielding than in calling a free-standing proc).

def thrice()
  3.times { yield }
end

thrice { puts "Hello World!" }
# >> Hello World!
# >> Hello World!
# >> Hello World!

That doesn't have any impact on your original argument though. You
can't reimplement yield in Ruby with the reflection it offers right
now.

[Florian Gross]

> Rationals are:
>
>   * you can detect methods that don't take blocks, that
>     currently ignored silently.

Currently, it is still possible for the method to check for blocks it
doesn't want by itself, though. (raise if block_given?)

[Yukihiro Matsumoto]

Hi,

In message "Re: Yield should be renamed call_block"
    on Tue, 10 Jul 2007 06:51:03 +0900, Florian Gross <florgro@...> writes:

|Currently, it is still possible for the method to check for blocks it
|doesn't want by itself, though. (raise if block_given?)

If you check explicitly, yes.  But implicit is better than explicit,
if you and computer feel same way.

                                                        matz.

[Charles Oliver Nutter-2]

Florian Gross wrote:

>> This is why if you ever want to pass a given block
>> to another method, you must capture it in a block argument, and also why
>> yielding to a block is much faster than calling a proc (since there's
>> less overhead in yielding than in calling a free-standing proc).
>
> def thrice()
>   3.times { yield }
> end
>
> thrice { puts "Hello World!" }
> # >> Hello World!
> # >> Hello World!
> # >> Hello World!
>
> That doesn't have any impact on your original argument though. You
> can't reimplement yield in Ruby with the reflection it offers right
> now.

Yeah, you're not redefining yield, you're wrapping a method that accepts
a block with another method that accepts a block. There's no way to
define a method that uses the current method's block, e.g.:

# some magic to define my_yield here

def foo
   my_yield(1)
end

foo {|x| puts x}

There is another keyword that passes along the same block though: super.

class A
   def foo
     yield
   end
end

class B < A
   def foo
     super
   end
end

B.new { puts 'here' }

But we're just swapping keywords, and it's not generally applicable.

- Charlie

[Bertram Scharpf]

Hi,

Am Dienstag, 10. Jul 2007, 08:05:04 +0900 schrieb Yukihiro Matsumoto:
> In message "Re: Yield should be renamed call_block"
>     on Tue, 10 Jul 2007 06:51:03 +0900, Florian Gross <florgro@...> writes:
>
> |Currently, it is still possible for the method to check for blocks it
> |doesn't want by itself, though. (raise if block_given?)
>
> If you check explicitly, yes.  But implicit is better than explicit,
> if you and computer feel same way.

There is a implication uncertainity relation: either
`&block' is implicit or `raise if block_given?' is.

In 95% of my code it's more convenient to have `&block'
implicit. I _feel_ much better with the former.

Bertram


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

[Yukihiro Matsumoto]

Hi,

In message "Re: Yield should be renamed call_block"
    on Tue, 10 Jul 2007 09:10:07 +0900, Bertram Scharpf <lists@...> writes:

|> If you check explicitly, yes.  But implicit is better than explicit,
|> if you and computer feel same way.
|
|There is a implication uncertainity relation: either
|`&block' is implicit or `raise if block_given?' is.

I meant 'raise if block_given?' being explicit

                                                        matz.

[Charles Oliver Nutter-2]

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.

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

[Bertram Scharpf]

Hi,

Am Dienstag, 10. Jul 2007, 13:28:27 +0900 schrieb Yukihiro Matsumoto:

> In message "Re: Yield should be renamed call_block"
>     on Tue, 10 Jul 2007 09:10:07 +0900, Bertram Scharpf <lists@...> writes:
>
> |> If you check explicitly, yes.  But implicit is better than explicit,
> |> if you and computer feel same way.
> |
> |There is a implication uncertainity relation: either
> |`&block' is implicit or `raise if block_given?' is.
>
> I meant 'raise if block_given?' being explicit

Sorry. This discussion really drives me round the bend.

Bertram


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

[Robert Dober]

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.
> 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
>
> James Edward Gray II
>
>
Cheers
Robert

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