Yield should be renamed call_block

Ruby
41

On 7/10/07, [email protected] [email protected] wrote:

Hi –

Interesting – I didn’t know that would happen. However, I think
James’s point was about using the block in a variable in the method
(e.g., for calling another method using the same block).
Am I missing something here?

def x
y &Proc.new
end

that would be the equivalent to the preferred

def x &blk
y &blk
end

Right?

Robert

42

Hi –

On Tue, 10 Jul 2007, Robert D. wrote:

On 7/9/07, James Edward G. II [email protected] wrote:

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

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.

And to me, unless you absolutely need it, it’s line noise. So I guess
we cancel each other out :slight_smile: But I’ve given up on “readability” as a
criterion of anything. It’s too much like “intuitiveness” – we’ve
all got our own :slight_smile:

I’ve always thought of the yield mechanism as one of the most
strikingly elegant and expressive things in Ruby. (More subjective
judgment :slight_smile: I’m actually very surprised to hear that it’s likely to
disappear, or change considerably.

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

Interesting – I didn’t know that would happen. However, I think
James’s point was about using the block in a variable in the method
(e.g., for calling another method using the same block).

David

43

I’ve always thought of the yield mechanism as one of the most
strikingly elegant and expressive things in Ruby. (More subjective
judgment :slight_smile: 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

44

On 7/10/07, [email protected] [email protected] wrote:
Sorry for the second post :frowning:

I’ve always thought of the yield mechanism as one of the most
strikingly elegant and expressive things in Ruby. (More subjective
judgment :slight_smile: I’m actually very surprised to hear that it’s likely to
disappear, or change considerably.

I missed that point.
I completely agree with you, I need &blk – with or without sigil :wink:
– and I need
yield, absolutely !!!
R.

45

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

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

46

On Jul 10, 2007, at 2:28 PM, [email protected] wrote:

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

47

Hi –

On Tue, 10 Jul 2007, Bharat R. wrote:

I’ve always thought of the yield mechanism as one of the most
strikingly elegant and expressive things in Ruby. (More subjective
judgment :slight_smile: 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.

It would bother me if the object were one where the concept of
“yielding” didn’t apply, like a Proc :slight_smile:

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

48

Hi,

In message “Re: Yield should be renamed call_block”
on Tue, 10 Jul 2007 00:55:04 +0900, [email protected] writes:

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

Since I am not a English speeker and I usually dont use that particlar
word, I feel like “yield” as rather like a symbol vaguly related to
passing valu to the blok.

Besides that, receivers often plays subjective roles for verbs (method
names), for example thread.kill or file.close, etc.

          matz.
49

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

Since I am not a English speeker and I usually dont use that particlar
word, I feel like “yield” as rather like a symbol vaguly related to
passing valu to the blok.

Besides that, receivers often plays subjective roles for verbs (method
names), for example thread.kill or file.close, etc.

That’s true, but I shared the same confusion as David does when I was
playing with 1.9.
block.yield to me sounds like the opposite of block.call

In fact, my first instinct was to think this allowed currying for some
reason.

like

block = lambda { |x,y| x + y + 3 }
block2 = block.yield(2)
block2.call(4) #=> 9

Of course, that imaginary syntax isn’t a good idea either, but that’s
what came to mind.

50

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

51

On Jul 10, 2007, at 3:33 PM, [email protected] wrote:

Since I am not a English speeker and I usually dont use that
particlar
word, I feel like “yield” as rather like a symbol vaguly related to
passing valu to the blok.

Vagueness would be OK, maybe, but the problem is bigger than that:
it’s that “block.yield” just doesn’t express what’s happening.

i’m with matz on this one

block.yield

reads, to me, simple as

‘doing my own thing…’

block.yield ‘control to you’

or

accum << block.yield

it’s especially easy if you happen to think of blocks as a
specialized form of co-routinues, which i happen to.

i have always disliked

block.call

precisely because you are NOT doing that. calling a function/method
whatever implies a call stack and clean environment. with blocks we
actually invoke/yield to them in the particular way that makes them
useful - which is to say that they execute within the closure in
which they were defined. in general i think it’s highly damaging to
align the terminology of methods and blocks, since the two operation
in entirely different ways wrst closures and people generally have a
very hard time with the concept of a real closure and all it’s
implications.

2cts.

regards.

-a

52

While we are talking about the methodize-ation of keywords, any chance
we
can get return “methodized”? (I mean callcc is a method, and raise is a
method, so it’s not like call-stack manipulating methods don’t already
exist…)

53

On Wed, Jul 11, 2007 at 07:36:34AM +0900, ara.t.howard wrote:

i’m with matz on this one

block.yield

reads, to me, simple as

‘doing my own thing…’

block.yield ‘control to you’

Speaking more generally . . .

The way I’ve always read the object.message syntax is that you’re saying
something like “Hey, Object! I want you to [yield].” Substitute the
particular message you’re sending for [yield] as necessary.

54

Hi –

On Wed, 11 Jul 2007, Yukihiro M. wrote:

Since I am not a English speeker and I usually dont use that particlar
word, I feel like “yield” as rather like a symbol vaguly related to
passing valu to the blok.

Vagueness would be OK, maybe, but the problem is bigger than that:
it’s that “block.yield” just doesn’t express what’s happening.

Besides that, receivers often plays subjective roles for verbs
(method names), for example thread.kill or file.close, etc.

Those aren’t the same, though:

kill this thread
close this file stream
yield this function??? <= doesn’t work, in terms of language

It’s gets even more confusing with an argument:

block.yield(x)

Are you yielding x, or the block?

Basically “yield” is a great name for a keyword (please don’t remove
it ! :slight_smile: but very problematic as a “call” alias. I’d advise fairly
strongly against using it that way.

David

55

Hi –

On Wed, 11 Jul 2007, ara.t.howard wrote:

i’m with matz on this one

block.yield

reads, to me, simple as

‘doing my own thing…’

block.yield ‘control to you’

But “yield” does not mean “take control”. It means relinquish
control. That’s why it makes sense as a control-flow directive –
control, independent of any specific object-messaging, switches upon
“yield” – and not as a message being sent to an object. That object
is not supposed to relinquish control, so it doesn’t make sense to ask
it to.

And if you interpret it as more like “thread.kill” than like
“string.split” (i.e., telling the system to kill a thread, rather than
telling a string to split), then you’re telling the system to yield a
block. But the system doesn’t yield blocks; it yields (relinquishes
control) to blocks.

I suspect that if we didn’t have the ‘yield’ keyword and the process
of making a transition to having it be message-style, I don’t think
“yield” would ever show up as a suggestion for a name for this method
(though of course an astonishing number of terms show up in the
various free-for-all method-name suggestion fests :slight_smile:

or

accum << block.yield

That still doesn’t tell me what it means for a block to yield. I
think I smiley-ly suggested:

yield >> block

earlier, but I actually think that’s much better than block.yield.
Make yield explicitly yield to a variable, if necessary, but don’t
send the message “yield” to an object that has no intention of
yielding anything, nor any intention of being yielded.

it’s especially easy if you happen to think of blocks as a specialized form
of co-routinues, which i happen to.

I do too; they’re co-routines to which control is yielded. They yield
control back, but that’s another matter :slight_smile:

David

56

Hi –

On Wed, 11 Jul 2007, Chad P. wrote:

block.yield ‘control to you’

Speaking more generally . . .

The way I’ve always read the object.message syntax is that you’re saying
something like “Hey, Object! I want you to [yield].” Substitute the
particular message you’re sending for [yield] as necessary.

Exactly – blocks don’t yield, so let’s not ask them to :slight_smile:

David

57

On Wed, Jul 11, 2007 at 09:28:14AM +0900, [email protected] wrote:

‘doing my own thing…’

block.yield ‘control to you’

Speaking more generally . . .

The way I’ve always read the object.message syntax is that you’re saying
something like “Hey, Object! I want you to [yield].” Substitute the
particular message you’re sending for [yield] as necessary.

Exactly – blocks don’t yield, so let’s not ask them to :slight_smile:

Is the word “accept” being used for anything?

58

Hi –

On Wed, 11 Jul 2007, Chad P. wrote:

Exactly – blocks don’t yield, so let’s not ask them to :slight_smile:

Is the word “accept” being used for anything?

$ ri Proc#accept
Nothing known about Proc#accept

Doesn’t look like it :slight_smile:

David

59

Hi,

In message “Re: Yield should be renamed call_block”
on Wed, 11 Jul 2007 08:43:12 +0900, “Logan C.”
[email protected] writes:

|While we are talking about the methodize-ation of keywords, any chance we
|can get return “methodized”? (I mean callcc is a method, and raise is a
|method, so it’s not like call-stack manipulating methods don’t already
|exist…)

I think we will lose great chance of optimization by making return,
break, etc. into methods.

          matz.
60

On Wed, Jul 11, 2007 at 09:37:56AM +0900, [email protected] wrote:

On Wed, 11 Jul 2007, Chad P. wrote:

Is the word “accept” being used for anything?

$ ri Proc#accept
Nothing known about Proc#accept

Doesn’t look like it :slight_smile:

It seems like words such as the following would be appropriate:

accept
receive
request

I don’t know about “call”, though. Maybe?

Maybe I’m not the guy to ask, though.