New Local Variable Scope rule

ruby-talk
21

Why would we have anything defined here although both blocks are not
executed in this example? Slowly I'm loosing grips here... A summary was
definitely in order.

because ruby don't need to execute a block to see local variables :slight_smile:

Guy Decoux

22

ts <decoux@moulon.inra.fr> writes:

I admit I'm confused by this. Is 'local' being introduced? And if
>a> is a block variable, isn't it local to the block anyway?

[ruby-talk:63199]

and what do you do with this ?

Thread.new { a = 1 } # like Proc or like lambda ?
NewClass.new { a = 1 } # like Proc or like lambda ?
new_method { a = 1 } # like Proc or like lambda ?

I'm not sure what you mean. Do you mean what would I do if I were
designing Ruby 2.0,

yes,

                   or what do I think Matz will have them do? I
don't know, since I still don't know the answer to the above (whether
Proc and lambda will be different in this respect). I think maybe you
think that I know, but I don't :slight_smile:

If you introduce a difference between Proc and lambda, what do you do
with the examples that I've given ?

Thread will work like Proc or like lambda ?

Guy Decoux

23

Yes, that is one thing I think I had understood. So I
had convinced myself that the new rule (in 2.0) should

be interpreted as:

if a new variable is created inside a lambda it’s
scope
is extended over the “syntacticaly enclosing” scope
i.e. where the lambda is first “seen” and not where
it may be later executed.

– shanko

···

— ts decoux@moulon.inra.fr wrote:

because ruby don’t need to execute a block to see
local variables :slight_smile:

Do you Yahoo!?
Yahoo! Tax Center - File online by April 15th
http://taxes.yahoo.com/filing.html

24

Hi –

ts decoux@moulon.inra.fr writes:

ts decoux@moulon.inra.fr writes:

I admit I’m confused by this. Is ‘local’ being introduced? And if

a> is a block variable, isn’t it local to the block anyway?

[ruby-talk:63199]

and what do you do with this ?

Thread.new { a = 1 } # like Proc or like lambda ?
NewClass.new { a = 1 } # like Proc or like lambda ?
new_method { a = 1 } # like Proc or like lambda ?

I’m not sure what you mean. Do you mean what would I do if I were
designing Ruby 2.0,

yes,

               or what do I think Matz will have them do?  I

don’t know, since I still don’t know the answer to the above (whether
Proc and lambda will be different in this respect). I think maybe you
think that I know, but I don’t :slight_smile:

If you introduce a difference between Proc and lambda, what do you do
with the examples that I’ve given ?

Thread will work like Proc or like lambda ?

Every code block will work (I assume!) like every other code block.
(Otherwise learning how to use blocks would be like learning irregular
verbs.) So if Thread.new takes a block, that’s exactly the same as
any other method taking a block.

But that may or may not mean that Proc objects and lambdas, neither of
which (as I understand it) are the same thing strictly speaking as
code blocks (the thing that would be called a Block if there were a
Block class :slight_smile: behave the same as each other.

Going back to the original point (more or less): I’m just a little
perplexed by the whole idea of closures (blocks, Procs, lambdas)
having this compile-time effect on local variables in their context of
creation.

David

···

–
David A. Black
dblack@wobblini.net

25

Going back to the original point (more or less): I'm just a little
perplexed by the whole idea of closures (blocks, Procs, lambdas)
having this compile-time effect on local variables in their context of
creation.

Well, actually this is at compile time that ruby make the difference
between local, block-local variable and method call.

If I've well understood, in 2.0 this is not changed : the only difference
is how ruby make the difference between local and block-local variable.

Now the worst case is perhaps this

svg% cat b.rb
#!/usr/bin/ruby
thr =
5.times do |i|
   thr << Thread.new do
      a = i
      Thread.stop
      puts a
   end
end

thr.each {|t| t.run }
svg%

svg% b.rb
0
1
2
3
4
svg%

I'm not sure but I think that for 2.0 all threads will give the same
result.

Do these constructs are really frequent ? I don't know.

The best way do know this is to modify your personnal version of ruby and
use it : you can have surprise :-)))

Guy Decoux

26

Hi –

ts decoux@moulon.inra.fr writes:

Going back to the original point (more or less): I’m just a little
perplexed by the whole idea of closures (blocks, Procs, lambdas)
having this compile-time effect on local variables in their context of
creation.

Well, actually this is at compile time that ruby make the difference
between local, block-local variable and method call.

If I’ve well understood, in 2.0 this is not changed : the only difference
is how ruby make the difference between local and block-local variable.

That’s my understanding too (see above). I’m just not entirely
comfortable with it.

Now the worst case is perhaps this

svg% cat b.rb
#!/usr/bin/ruby
thr =
5.times do |i|
thr << Thread.new do
a = i
Thread.stop
puts a
end
end

thr.each {|t| t.run }
svg%

svg% b.rb
0
1
2
3
4
svg%

I’m not sure but I think that for 2.0 all threads will give the same
result.

I assume so; it’s like your other example, where 2.0 behaves the way
pre-2.0 does with “a = nil” before the block. To avoid it I guess
you’d have to do:

… Thread.new do |a| # etc.

to create a new ‘a’ each time.

David

···

–
David A. Black
dblack@wobblini.net

27

David Alan Black wrote:

Hi –

ts decoux@moulon.inra.fr writes:

“D” == David Alan Black dblack@wobblini.net writes:

Going back to the original point (more or less): I’m just a little
perplexed by the whole idea of closures (blocks, Procs, lambdas)
having this compile-time effect on local variables in their context of
creation.

Well, actually this is at compile time that ruby make the difference
between local, block-local variable and method call.

If I’ve well understood, in 2.0 this is not changed : the only difference
is how ruby make the difference between local and block-local variable.

That’s my understanding too (see above). I’m just not entirely
comfortable with it.

Now the worst case is perhaps this

svg% cat b.rb
#!/usr/bin/ruby
thr =
5.times do |i|
thr << Thread.new do
a = i
Thread.stop
puts a
end
end

thr.each {|t| t.run }
svg%

svg% b.rb
0
1
2
3
4
svg%

I’m not sure but I think that for 2.0 all threads will give the same
result.

I assume so; it’s like your other example, where 2.0 behaves the way
pre-2.0 does with “a = nil” before the block. To avoid it I guess
you’d have to do:

… Thread.new do |a| # etc.

to create a new ‘a’ each time.

David

Feels awk-ish to me, the way you have to declare local variables by
stuffing them in the parameter list. And awk doesn’t have the easy
ability to convert a list into a parameter list. So what do you do if
you have a parameter list you don’t know how long it will be but you
still need local variables?

This method bothers me considerably. It may make it easier for short
code, but I really don’t mind stuffing a “var = nil” before doing
something in a block, that to me seems logical. Kind of annoying, but
logical.

Charlie

28

  ... Thread.new do |a| # etc.

or like this

             local do |a|

and you see immediately an advantage : you can cut/paste your block and
ruby will do always the same thing because the block-local variable is
directly associated with its block via ||

This is not true with 1.8

Guy Decoux

29

Hi –

ts decoux@moulon.inra.fr writes:

… Thread.new do |a| # etc.

or like this

         local do |a|

and you see immediately an advantage : you can cut/paste your block and
ruby will do always the same thing because the block-local variable is
directly associated with its block via ||

This is not true with 1.8

Is a ‘local’ keyword being introduced in 2.0? I can’t find mention of
it.

David

···

–
David A. Black
dblack@wobblini.net

30

Is a 'local' keyword being introduced in 2.0? I can't find mention of
it.

[ruby-talk:97250] which give reference to [ruby-talk:63199] :slight_smile:

Guy Decoux

31

David Alan Black wrote:

Is a ‘local’ keyword being introduced in 2.0? I can’t find mention of
it.

All local would be is …

def local
yield
end

···

–
– Jim Weirich jim@weirichhouse.org http://onestepback.org

“Beware of bugs in the above code; I have only proved it correct,
not tried it.” – Donald Knuth (in a memo to Peter van Emde Boas)

32

In article 4082CA8A.7010605@weirichhouse.org,
: David Alan Black wrote:
: > Is a ‘local’ keyword being introduced in 2.0? I can’t find mention of
: > it.
:
: All local would be is …
:
: def local
: yield
: end

Hrmm. Not QUITE. It complained at me when I tried that.

[ruby-talk:64791]

I’m not sure |a| will accept an arbitrary num. of args. in the future
(you might need |*a|).

A slight variation on that though…

irb(main):007:0> def local(&block);yield block;end

I don’t think this is doing what you think it is doing :wink:

def local(&block);yield block;end
=> nil
local{|x| p x}
#Proc:0x401f8ee0@:2(irb)
=> nil

for the matter,

def local; yield 1;end
(irb):3: warning: method redefined; discarding old local
=> nil
local{|x| p x}
1
=> nil
local{|a,b,c| }
=> nil

···

On Mon, Apr 19, 2004 at 04:14:10AM +0900, Dave Brown wrote:

Jim Weirich jim@weirichhouse.org wrote:

–
Running Debian GNU/Linux Sid (unstable)
batsman dot geo at yahoo dot com

i dont even know if it makes sense at all :slight_smile: This is an experimental patch
for an experimental kernel :))
– Ingo Molnar on linux-kernel