[#6363] Re: rescue clause affecting IO loop behavior — ts <decoux@...>

>>>>> "D" == David Alan Black <dblack@candle.superlink.net> writes:

17 messages 2000/11/14
[#6367] Re: rescue clause affecting IO loop behavior — David Alan Black <dblack@...> 2000/11/14

Hello again --

[#6582] best way to interleaf arrays? — David Alan Black <dblack@...>

Hello --

15 messages 2000/11/26

[#6646] RE: Array Intersect (&) question — Aleksi Niemel<aleksi.niemela@...>

Ross asked something about widely known and largely ignored language (on

23 messages 2000/11/29
[#6652] RE: Array Intersect (&) question — rpmohn@... (Ross Mohn) 2000/11/29

aleksi.niemela@cinnober.com (Aleksi Niemel) wrote in

[#6723] Re: Array Intersect (&) question — Mathieu Bouchard <matju@...> 2000/12/01

> >Use a hash. Here's code to do both and more. It assumes that

[#6656] printing/accessing arrays and hashes — raja@... (Raja S.)

I'm coming to Ruby with a Python & Common Lisp background.

24 messages 2000/11/30

[ruby-talk:6670] Re: each/for binding confusion and resolution

From: hipster <hipster@...4all.nl>
Date: 2000-11-30 08:43:58 UTC
List: ruby-talk #6670
On Thu, 30 Nov 2000  08:10:01 +0900, Steven Grady wrote:
> As I am still learning the language, I am hitting things which are
> confusing.  I thought I'd share one with people here -- perhaps it
> may spark some conversation as to whether it violates POLS.
> 
> In essence, one problem I had came down to the following:
> 
>     procs = []
>     for v in [1, 2]
> 	procs << proc { v }
>     end
>     procs.collect { |p| p.call }	-> [2, 2]
> 
> I was hoping for [1, 2].
[snip]
> After some exploration (and reading a bit of the book), I discovered that
> an alternate solution is:
>     procs = []
>     [1, 2].each { |v|
> 	procs << proc { v }
>     }   
>     procs.collect { |p| p.call }	-> [1, 2]

So far so good. Now try running these snippets after each other:

-> [2,2]
-> [2,2]

Does this relate to the block-local variables discussion earlier? If
run separate, the 2nd script has a local v inside the block. If run
after each other, the v inside the 2nd block refers to the globally
defined v, and thus the lambdas refer to the same objects. This can be
validated by returning v.id instead of v.

Would, a construct similar to Thread.new,

	proc([arg*]) { |args| block } -> aProc

reduce the surprise? (I may overlook some binding semantics here, just
an idea)

	Michel

In This Thread