Re: lazy.rb 0.9.5 -- transparent futures!

You can just do

table_name = “CUSTOMERS”
x = promise { table_name }
puts x
=> “CUSTOMERS”

though you have to then make sure that you leave that table_name
variable alone.

table_name = “CUSTOMERS”
x = promise { table_name }
table_name = “MONKEYS”
puts x
=> “MONKEYS”


From: Shashank D. [mailto:[email protected]]
Sent: Thursday, 23 February 2006 9:15 AM
To: ruby-talk ML
Cc: [email protected]
Subject: Re: [ANN] lazy.rb 0.9.5 -- transparent futures!


Hi,

I have a feature request (along with a quick-hack solution).

Please ignore if this is already done or sounds crazy. :-)

Problem: All the promises I make, cannot have any arguments ! !

So something like this is what I have in mind:

x = promise("CUSTOMERS") { |table_name|

long_running_query(table_name)}

Admitedly, in this one-liner it does not make much sense. But if

the block had many many lines of code and referred to the block variable
at multiple places, suddenly it would be mean more to me.

I have attached my hackish solution without really thinking all

the way thru.
Thanks,

-- Shashank


MenTaLguY <[email protected]> wrote:
I'd like to announce a new version of lazy.rb -- this one

offering
thread safety and transparent futures!

Here's the web site, complete with gem and tarball downloads,

plus a bit
of documentation:

http://moonbase.rydia.net/software/lazy.rb/

Bug reports would be very, very welcome.

Yahoo! Mail
Use Photomail

<http://pa.yahoo.com/*http://us.rd.yahoo.com/evt=38867/*http://photomail
.mail.yahoo.com> to share photos without annoying attachments.

table_name = “CUSTOMERS”
x = promise {table_name.dup}
table_name = “MONKEYS”
puts x
=>“CUSTOMERS”

Would avoid the problem. Though it’s good to point out that you
likely want to avoid changing the state of any variable that’s
captured by a promise closure (unless of course you plan on exploiting
just that).

Unlikely. The variables passed into the promise would still have
their references to the outside. You get exactly the same effect as
capturing the variables in a closure and in fact, the given examples
are kinda contrived, it would make more sense to assign CUSTOMERS as a
local variable inside of the promise block, because then it can’t be
affected outside of the closure.

However, currently, there IS a block parameter (that of the promise
itself, something to do with circular programming, which sounds
intriguing, but I have hella no idea what it means [PLEASE SEND
LINKS]), but it doesn’t seem like you’d use it in most cases.

If you wanted something like, I dunno, currying a promise, you could
just wrap it in a lambda.

Hi,

Daniel N. [email protected] wrote: table_name = “CUSTOMERS”
x = promise {table_name.dup}
table_name = “MONKEYS”
puts x
=>“CUSTOMERS”

Would avoid the problem. Though it’s good to point out that you
likely want to avoid changing the state of any variable that’s
captured by a promise closure (unless of course you plan on exploiting
just that).

All this being said, is there any merit in the idea of passing block
parameters? I was toying with it briefly and decided to give it a shot
on a whim. Will try and come up with a more convincing answer.

Thanks for all your inputs.
– shanko

On Thu, 2006-02-23 at 10:14 +0900, Daniel N. wrote:

table_name = “CUSTOMERS”
x = promise {table_name.dup}
table_name = “MONKEYS”
puts x
=>“CUSTOMERS”

Would avoid the problem.

Actually, no. String#dup wouldn’t get called until the promise was
demanded, by which time table_name refers to a different string.

-mental

Daniel N. wrote:

table_name = “CUSTOMERS”
x = promise {table_name.dup}
table_name = “MONKEYS”
puts x
=>“CUSTOMERS”

Would avoid the problem. Though it’s good to point out that you
likely want to avoid changing the state of any variable that’s
captured by a promise closure (unless of course you plan on exploiting
just that).

Hmmm … I just tried it and got “MONKEYS” for the result. It makes
sense becase by the time table_name is dup’ed in the promise, it has
already been modified.

This would do it:

def table_promise(name)
promise { name }
end

table_name = “CUSTOMERS”
x = table_promise(table_name)
table_name = “MONKEYS”
puts x # => “CUSTOMERS”


– Jim W.

I don’t think I understand what’sgoing on th… oh wait. I see.

both table_name and name are pointing to “CUSTOMERS” and then only
table_name is pointing to “MONKEYS”

Yes, see, the thing that’s important to consider is that I’m dumb.

tries out Mental’s examples, figures out how they work

Woah, that’s some powerful ju-ju. Maybe I should go and futz with
GhostWriter again anyhow…

On Thu, 2006-02-23 at 13:21 +0900, Daniel N. wrote:

However, currently, there IS a block parameter (that of the promise
itself, something to do with circular programming, which sounds
intriguing, but I have hella no idea what it means [PLEASE SEND
LINKS]), but it doesn’t seem like you’d use it in most cases.

Here are a couple trivial examples…

Building a circular data structure (a linked list in this case):

def build_circular_list( *stuff )
promise { |result|
if stuff.empty?
nil
else
list = result
stuff.reverse.each { |thing|
list = [ thing, list ]
}
list
end
}
end

Padding lines of text to a maximum width in a single pass:

def pad_lines( lines )
promise { |result|
max_width = 0
padded_lines = []

 lines.each { |line|
   max_width = line.length if line.length > max_width
   padded_lines.push promise { "%*s" % [ result[1], line ] }
 }

 [ padded_lines, max_width ]

}[0]
end

-mental