[#5218] Ruby Book Eng tl, ch1 question — Jon Babcock <jon@...>

13 messages 2000/10/02

[#5404] Object.foo, setters and so on — "Hal E. Fulton" <hal9000@...>

OK, here is what I think I know.

14 messages 2000/10/11

[#5425] Ruby Book Eng. tl, 9.8.11 -- seishitsu ? — Jon Babcock <jon@...>

18 messages 2000/10/11
[#5427] RE: Ruby Book Eng. tl, 9.8.11 -- seishitsu ? — OZAWA -Crouton- Sakuro <crouton@...> 2000/10/11

At Thu, 12 Oct 2000 03:49:46 +0900,

[#5429] Re: Ruby Book Eng. tl, 9.8.11 -- seishitsu ? — Jon Babcock <jon@...> 2000/10/11

Thanks for the input.

[#5432] Re: Ruby Book Eng. tl, 9.8.11 -- seishitsu ? — Yasushi Shoji <yashi@...> 2000/10/11

At Thu, 12 Oct 2000 04:53:41 +0900,

[#5516] Re: Some newbye question — ts <decoux@...>

>>>>> "D" == Davide Marchignoli <marchign@di.unipi.it> writes:

80 messages 2000/10/13
[#5531] Re: Some newbye question — matz@... (Yukihiro Matsumoto) 2000/10/14

Hi,

[#5544] Re: Some newbye question — Davide Marchignoli <marchign@...> 2000/10/15

On Sat, 14 Oct 2000, Yukihiro Matsumoto wrote:

[#5576] Re: local variables (nested, in-block, parameters, etc.) — Dave Thomas <Dave@...> 2000/10/16

matz@zetabits.com (Yukihiro Matsumoto) writes:

[#5617] Re: local variables (nested, in-block, parameters, etc.) — "Brian F. Feldman" <green@...> 2000/10/16

Dave Thomas <Dave@thomases.com> wrote:

[#5705] Dynamic languages, SWOT ? — Hugh Sasse Staff Elec Eng <hgs@...>

There has been discussion on this list/group from time to time about

16 messages 2000/10/20
[#5712] Re: Dynamic languages, SWOT ? — Charles Hixson <charleshixsn@...> 2000/10/20

Hugh Sasse Staff Elec Eng wrote:

[#5882] [RFC] Towards a new synchronisation primitive — hipster <hipster@...4all.nl>

Hello fellow rubyists,

21 messages 2000/10/26

[ruby-talk:5820] Re: local variables (nested, in-block, parameters, etc.)

From: "John Small" <jsmall@...>
Date: 2000-10-24 16:12:56 UTC
List: ruby-talk #5820
Hi Matz,

this seems consistent if you think of block parameters as well as block
local parameters as merely being a call by name closure of the surrounding
context.   If the block parameters and block local variables are not
referred
to by name in the enclosing local context, after as well as before the block
expression then these block parameters and local variables are local to
the block only.

In other words block parameters and block locals are in block scope
unless they are defined as local to the context the block closure sees both
before and after the block expression.

I have another request and since I've only been programming in Ruby under
a week it might be a dumb request.  If there are way to exit a block used
in conjunction with an iterator/enumerator?  In other words is there a way
to break out of the loop:

        [1,2,3].each { | i | print "\n#{i}"; break if (i >= 2) }

which would produce:

    1
    2

John
p.s.  I got a good chunk of that Ruby ODBC driver finished over the weekend
but I'm not pulled off working on a rush job in Perl.

----- Original Message -----
From: "Yukihiro Matsumoto" <matz@zetabits.com>
To: "ruby-talk ML" <ruby-talk@netlab.co.jp>
Sent: Tuesday, October 24, 2000 10:59 AM
Subject: [ruby-talk:5819] Re: local variables (nested, in-block, parameters,
etc.)


> Hi,
>
> In message "[ruby-talk:5818] Re: local variables (nested, in-block,
parameters, etc.)"
>     on 00/10/24, ts <decoux@moulon.inra.fr> writes:
>
> |G> So, does this amount to it *creating* a local var to bind to if no
local
> |G> var already exists?  GREAT idea. And I don't think it would cause much
> |G> incompatibility since if no local var was seen, then it probably isn't
> |G> used later, either (or if it is, is probably initialized). The only
> |
> | It break some closure, for example in test.rb
> |
> |   eval "(0..9).each{|i5| $x[i5] = proc{i5*2}}", x
> |   test_ok($x[4].call == 8)
>
> I'm thinking of adding a new rule that the scope of a new block
> parameter (|| variable) is extended if it is referred out of the
> block.  So i5 in
>
> >   eval "(0..9).each{|i5| $x[i5] = proc{i5*2}}", x
> >   test_ok($x[4].call == 8)
>
> will be in-block variable (as is now).  But i6 in
>
>   [1,2,3].each{|i6| break if i6 % 2 == 0}
>   p i6    # referred out of a block
>
> will be a plain local variable.  How do you think?
> Too complicated?
>
> matz.
>


In This Thread