On 7/9/07, John J. [email protected] 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.
On Jul 9, 2007, at 8:29 AM, John J. wrote:
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 G. II
On Jul 9, 2007, at 9:27 AM, John J. wrote:
|
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 B. http://agileconsultingllc.com
[email protected]
Hi,
In message “Re: Yield should be renamed call_block”
on Mon, 9 Jul 2007 22:14:01 +0900, Bertram S.
[email protected] writes:
|Am Montag, 09. Jul 2007, 21:06:58 +0900 schrieb Yukihiro M.:
|> […] 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.
Yukihiro M. 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):
-
I have to plead ignorance. I do not know the language history very
well. What is CLU?
-
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
On 7/9/07, Bharat R. [email protected] wrote:
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.
Hi –
On Mon, 9 Jul 2007, Simen E. wrote:
On 7/9/07, John J. [email protected] 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
Hi –
On Mon, 9 Jul 2007, Yukihiro M. wrote:
|syntax be removed, in favor of Proc arguments?
- 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
Hi,
In message “Re: Yield should be renamed call_block”
on Mon, 9 Jul 2007 23:59:35 +0900, Bharat R.
[email protected] 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.
James Edward G. II wrote:
On Jul 9, 2007, at 8:29 AM, John J. 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).
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.
On Jul 9, 2007, at 11:43 AM, Yukihiro M. wrote:
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 B. http://agileconsultingllc.com
[email protected]
Hi,
In message “Re: Yield should be renamed call_block”
on Tue, 10 Jul 2007 06:51:03 +0900, Florian G.
[email protected] 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.
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?)
Florian G. wrote:
>> 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.
Hi,
Am Dienstag, 10. Jul 2007, 08:05:04 +0900 schrieb Yukihiro M.:
In message “Re: Yield should be renamed call_block”
on Tue, 10 Jul 2007 06:51:03 +0900, Florian G. [email protected] 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
Yukihiro M. wrote:
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.
Hi,
In message “Re: Yield should be renamed call_block”
on Tue, 10 Jul 2007 09:10:07 +0900, Bertram S.
[email protected] 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.
Hi,
Am Dienstag, 10. Jul 2007, 13:28:27 +0900 schrieb Yukihiro M.:
In message “Re: Yield should be renamed call_block”
on Tue, 10 Jul 2007 09:10:07 +0900, Bertram S. [email protected] 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
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.
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 G. II
Cheers
Robert