Recently I was suprised by the behavior of "start = lambda { start }".
Now that I understand that, I am suprised that
a = 1
b = i if (i = a)
doesn't work.
T.
Trans wrote:
Recently I was suprised by the behavior of "start = lambda { start }".
Undecorated symbols aren't interpreted until they're executed. Ruby doesn't even know if the 'start' symbol inside the { ... } is a method or a local variable until it gets there. That's how I got away with a lot of my poetry stuff (and how other's've done the same). So "start = lambda { ADOSdsgfsdgsjT___SDdddd_____222__S224444449 soduihgsoihosidho5s2405987soos23h }" works just as well. (Hadn't followed the previous thread; you might've already figured this out.)
Now that I understand that, I am suprised that
a = 1
b = i if (i = a)doesn't work.
Yeah, that's just weirdness. Possibly because Matz feels local side-effects should move from left to right? In any case, you can do
a = 1
if (i = a) then b = i end
instead.
Devin
There was a thread on this a while back; apparently it is difficult to
implement this under the current parser:
http://rubyurl.com/k0u [1]
In the course sof the discussion, a patch was offered; but its creator
(the venerable Nobu) labeled it as a dirty hack.
cheers,
Mark
···
On 9/20/05, Trans <transfire@gmail.com> wrote:
Recently I was suprised by the behavior of "start = lambda { start }".
Now that I understand that, I am suprised thata = 1
b = i if (i = a)doesn't work.
Hi,
···
In message "Re: b = i if i = a doesn't work?" on Wed, 21 Sep 2005 07:22:07 +0900, Devin Mullins <twifkak@comcast.net> writes:
Recently I was suprised by the behavior of "start = lambda { start }".
Undecorated symbols aren't interpreted until they're executed.
"executed" is not a precise word. Local variables are not recognized
until their first assignments are seen in the program. In the
original case,
b = i if i = a
the first assignment "i = a" comes after the reference to the variable "i".
matz.