[ANN] lazy.rb 0.9.5 -- transparent futures!

ruby-talk
1

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 Date [mailto:shanko_date@yahoo.com]
  Sent: Thursday, 23 February 2006 9:15 AM
  To: ruby-talk ML
  Cc: mental@rydia.net
  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. :slight_smile:
   
  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 <mental@rydia.net> 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.

2

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).

···

On 2/22/06, Daniel Sheppard <daniels@pronto.com.au> wrote:

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 Date [mailto:shanko_date@yahoo.com]
        Sent: Thursday, 23 February 2006 9:15 AM
        To: ruby-talk ML
        Cc: mental@rydia.net
        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. :slight_smile:

        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 <mental@rydia.net> 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.

--
-Dan Nugent

3

Hi,

Daniel Nugent <nugend@gmail.com> 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

···

---------------------------------
Brings words and photos together (easily) with
PhotoMail - it's free and works with Yahoo! Mail.

4

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

-mental

···

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

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

Would avoid the problem.

5

Daniel Nugent 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 Weirich

--
Posted via http://www.ruby-forum.com/\.

6

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.

···

On 2/22/06, Shashank Date <shanko_date@yahoo.com> wrote:

Hi,

Daniel Nugent <nugend@gmail.com> 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

---------------------------------
Brings words and photos together (easily) with
PhotoMail - it's free and works with Yahoo! Mail.

--
-Dan Nugent

7

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 2/23/06, Jim Weirich <jim@weirichhouse.org> wrote:

Daniel Nugent 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 Weirich

--
Posted via http://www.ruby-forum.com/\.

--
-Dan Nugent

8

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

···

On Thu, 2006-02-23 at 13:21 +0900, Daniel Nugent 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.