Nikodemus Siivola wrote:
All this talk of block local variables reminded me of a funny trick…
As you know, receivers in ruby cannot change their class? No become, etc.
Right?Wrong:
#!/usr/bin/env ruby
a = proc { a = 1 }
puts “a is a #{a.class}”
a.call
puts “a is a #{a.class}”
no, it does change only one variable, not object variable is pointing to
source:
As you know, receivers in ruby cannot change their class? No become, etc.
Right?
Wrong:
no, not really : you make the confusion between a variable and an object.
For example with
a = b = 12
there are 2 variables and only one object, but with
a = [1, 2]
there are 1 variable and 3 objects
#!/usr/bin/env ruby
a = proc { a = 1 }
puts "a is a #{a.class}"
a.call
puts "a is a #{a.class}"
In your example, this is just that the variable make reference to another
object.
Guy Decoux
Hi,
In message “Trick or Bug?” on 02/06/12, Nikodemus Siivola tsiivola@cc.hut.fi writes:
As you know, receivers in ruby cannot change their class? No become, etc.
Right?Wrong:
#!/usr/bin/env ruby
a = proc { a = 1 }
puts “a is a #{a.class}”
a.call
puts “a is a #{a.class}”
It’s a trick, no bug.
matz.
Hi,
In message “Re: a new block parameter/variable notation (Re: ruby-dev summary 17252-17356)” on 02/06/12, Dave Thomas Dave@PragmaticProgrammer.com writes:
How hard would it be to issue a warning when a block parameter shadows
a local variable. Then we could simple say that in 1.10 it won’t be
supported; all block parameters are local. That would give folks a
year or so to change their code.
Not much, if I decide so. But I’m still not sure whether making
block parameters block-local is a good thing to do, when they are used
as iteration variables.
Plus, I feel like it’s a good chance to fix another Ruby’s design flaw
(i.e. lambda{|a|p a}.call(1,2,3) trap) at once.
matz.
What if we could do this:
5.times.do(a) a=gets; print a end
^?
Try to forget it, or you'll end up by writing very stupid thing (trust me
on the possibility to write stupid thing)
Guy Decoux
I just installed it and couldn’t figure out how to get it working
until I read the example in:
http://www.notwork.org/~gotoken/ruby/p/kakasi/
(It seems there’s no manpage for kakasi in the Debian distribution.)
Thanks for the pointer,
– Dossy
On 2002.06.13, Yukihiro Matsumoto matz@ruby-lang.org wrote:
In message “Japanese to Japanese translator?” > on 02/06/12, Dossy dossy@panoptic.com writes:
[…] is there something
out there that will translate from Japanese to Japanese,
specifically from hiragana/katakana/kanji to romaji?There’s a tool named “kakasi”.
–
Dossy Shiobara mail: dossy@panoptic.com
Panoptic Computer Network web: http://www.panoptic.com/
“He realized the fastest way to change is to laugh at your own
folly – then you can let go and quickly move on.” (p. 70)
Clever, but not correct, I think.
You’ve just pointed ‘a’ to a
different object, not changed the
class of the original object.
As I understand ‘become’ in Smalltalk
(and I don’t really) doesn’t it
operate on an object?
Hal Fulton
----- Original Message -----
From: “Nikodemus Siivola” tsiivola@cc.hut.fi
To: “ruby-talk ML” ruby-talk@ruby-lang.org
Sent: Wednesday, June 12, 2002 5:26 AM
Subject: Trick or Bug?
All this talk of block local variables reminded me of a funny trick…
As you know, receivers in ruby cannot change their class? No become, etc.
Right?Wrong:
#!/usr/bin/env ruby
a = proc { a = 1 }
puts “a is a #{a.class}”
a.call
puts “a is a #{a.class}”
Hi,
In message “Re: a new block parameter/variable notation (Re: ruby-dev summary 17252-17356)” on 02/06/13, “Christoph” chr_news@gmx.net writes:
This is not related, in svalue_to_avalue() try to change
I am not sure about your definition of ``related’’ but replace
Thank you for reporting, Christoph.
And thank you for fixing the bug, Guy.
matz.
I am not sure about your definition of ``related'' but replace
Well, I hope that you have seen that it's faster to write
A.new.method(:body).call
Guy Decoux
Nitpicker 
– Nikodemus
On Wed, 12 Jun 2002, Jakub Travnik wrote:
no, it does change only one variable, not object variable is pointing to
matz@ruby-lang.org (Yukihiro Matsumoto) writes:
Plus, I feel like it’s a good chance to fix another Ruby’s design flaw
(i.e. lambda{|a|p a}.call(1,2,3) trap) at once.
Is that the design flaw, or it is that
a = 1,2,3
works? It seems to me that the target (the lhs of an assignment or
the block parameter list) should determine whether you’re performing a
parallel assignment. If that was the case, then your example above
wouldn’t be a problem: your example would be a runtime error (too many
arguments) and mine would be a compile time error.
Cheers
Dave
From: “Nikodemus Siivola” tsiivola@cc.hut.fi
To: “ruby-talk ML” ruby-talk@ruby-lang.org
Sent: Wednesday, June 12, 2002 5:26 AM
Subject: Trick or Bug?All this talk of block local variables reminded me of a funny trick…
As you know, receivers in ruby cannot change their class? No become, etc.
Right?Wrong:
#!/usr/bin/env ruby
a = proc { a = 1 }
puts “a is a #{a.class}”
a.call
puts “a is a #{a.class}”Clever, but not correct, I think.
You’ve just pointed ‘a’ to a
different object, not changed the
class of the original object.As I understand ‘become’ in Smalltalk
(and I don’t really) doesn’t it
operate on an object?
I never used it. But if I remember correctly it changes ALL references to the
old object to a new object.
On Wednesday 12 June 2002 01:02 pm, Hal E. Fulton wrote:
----- Original Message -----
Hal Fulton
Hi,
In mail “Re: Japanese to Japanese translator?”
There’s a tool named “kakasi”.
I just installed it and couldn’t figure out how to get it working
until I read the example in:http://www.notwork.org/~gotoken/ruby/p/kakasi/
(It seems there’s no manpage for kakasi in the Debian distribution.)
kakasi is written in C. gotoken’s is its ruby interface.
You can get kakasi from here:
Debian might be providing a package.
Simple usage of kakasi:
~ % cat srcfile
今日も雨が降っている。
(It’s raining today, too.)
~ % cat srcfile | kakasi -Ha -Ka -Ja -Ea -ka -s
kyou mo ame ga futte iru .
– Minero Aoki
Dossy dossy@panoptic.com wrote:
“ts” decoux@moulon.inra.fr wrote in
…
I am not sure about your definition of ``related’’ but replace
Okay, I got it
Well, I hope that you have seen that it’s faster to write
A.new.method(:body).call
Hm, that’s way too close to do being useful;-)
/Christoph
Hi,
(i.e. lambda{|a|p a}.call(1,2,3) trap) at once.
Is that the design flaw, or it is that
a = 1,2,3
works? It seems to me that the target (the lhs of an assignment or
the block parameter list) should determine whether you’re performing a
parallel assignment. If that was the case, then your example above
wouldn’t be a problem: your example would be a runtime error (too many
arguments) and mine would be a compile time error.
Things are not that simple. Suppose we have:
def foo(obj)
obj.each do |x|
p x
end
end
then
foo([1,2,3])
is OK, but for
foo({1=>2, 2=>4})
the following assignments are done internally:
x = 1, 2
x = 2, 4
We can remove “a = 1,2,3” from the syntax, but we cannot remove it
from iterators.
matz.
In message “Re: a new block parameter/variable notation (Re: ruby-dev summary 17252-17356)” on 02/06/13, Dave Thomas Dave@PragmaticProgrammer.com writes:
Not really… not in this case, anyway.
Consider this code:
a = someObject
b = someObject
puts b.class
If you can write the “magic code”
that manipulates ‘a’ but not ‘b’
and then show that ‘b’ has changed,
I would believe you had accomplished
a ‘become’ operation…
Cheers,
Hal Fulton
----- Original Message -----
From: “Nikodemus Siivola” tsiivola@cc.hut.fi
To: “ruby-talk ML” ruby-talk@ruby-lang.org
Sent: Wednesday, June 12, 2002 6:53 AM
Subject: Re: Trick or Bug?
On Wed, 12 Jun 2002, Jakub Travnik wrote:
no, it does change only one variable, not object variable is pointing to
Nitpicker
ALL, that’s pretty frightening !
I guess that most of the time when I was referring to “become” so far
I should have used “become_a” instead. ‘a.become_a X; assert a.type == X’
Thanks for the clarification.
Yours,
Jean-Hugues
At 07:48 13/06/2002 +0900, you wrote:
On Wednesday 12 June 2002 01:02 pm, Hal E. Fulton wrote:
----- Original Message -----
From: “Nikodemus Siivola” tsiivola@cc.hut.fi
To: “ruby-talk ML” ruby-talk@ruby-lang.org
Sent: Wednesday, June 12, 2002 5:26 AM
Subject: Trick or Bug?All this talk of block local variables reminded me of a funny trick…
As you know, receivers in ruby cannot change their class? No become, etc.
Right?Wrong:
#!/usr/bin/env ruby
a = proc { a = 1 }
puts “a is a #{a.class}”
a.call
puts “a is a #{a.class}”Clever, but not correct, I think.
You’ve just pointed ‘a’ to a
different object, not changed the
class of the original object.As I understand ‘become’ in Smalltalk
(and I don’t really) doesn’t it
operate on an object?I never used it. But if I remember correctly it changes ALL references to
the
old object to a new object.Hal Fulton
Web: http://hdl.handle.net/1030.37/1.1
Phone: +33 (0) 4 92 27 74 17
matz@ruby-lang.org (Yukihiro Matsumoto) writes:
def foo(obj)
obj.each do |x|
p x
end
endfoo({1=>2, 2=>4})
the following assignments are done internally:
x = 1, 2
x = 2, 4We can remove “a = 1,2,3” from the syntax, but we cannot remove it
from iterators.
True, except if you wanted to force coercion into an array in block
arguments, you could always use the syntax
obj.each do |*x| …
That keeps the semantics clean and consistent
Cheers
Dave
Never claimed to have done that. Just a trick, and something that could
potentially be used to write something wery obfuscated. Isn’t it funny how
rare it is to come across a good obfuscating trick in ruby? It’s a kind of
magic…
– Nikodemus
On Thu, 13 Jun 2002, Hal E. Fulton wrote:
If you can write the “magic code”
that manipulates ‘a’ but not ‘b’
and then show that ‘b’ has changed,
I would believe you had accomplished
a ‘become’ operation…
Hi,
In message “Re: a new block parameter/variable notation (Re: ruby-dev summary 17252-17356)” on 02/06/13, Dave Thomas Dave@PragmaticProgrammer.com writes:
We can remove “a = 1,2,3” from the syntax, but we cannot remove it
from iterators.True, except if you wanted to force coercion into an array in block
arguments, you could always use the syntaxobj.each do |*x| …
That keeps the semantics clean and consistent
That makes the semantics small, but might hinder polymorphism.
Besides, the iteration variable assignment already is quite complex
(and we are not going to fix them all), so that making part of them
“small and clean” does not make them consistent as a whole, I’m afraid.
matz.