Tom Moertel's Weblog

def process
  sn = next_serial()
  log.info "process/#{sn}: stage 1"
  # ... do some work
  log.info "process/#{sn}: stage 2"
  # ... do some more work
  log.info "process/#{sn}: finished"
end

def process
  sn = next_serial()
  mylog("process", sn, "stage 1")
  # ... do some work
  mylog("process", sn, "stage 2")
  # ... do some more work
  mylog("process", sn, "finished")
end

def mylog(activity, sn, msg)
  log.info "#{activity}/#{sn} #{msg}"
end

def process
  sn = next_serial()
  llog = lambda { |s| mylog("process", sn, s) }
  llog["stage 1"]
  # ... do some work
  llog["stage 2"]
  # ... do some more work
  llog["finished"]
end

def process
  sn, llog = next_serial_and_logger("process")
  llog["stage 1"]
  # ... do some work
  llog["stage 2"]
  # ... do some more work
  llog["finished"]
end

def next_serial_and_logger(activity)
  sn = next_serial()
  [sn, lambda { |s| mylog(activity, sn, s) }]
end

Posted in programming, functional programming, programming languages, ruby
Tags closures, programming, ruby
12 comments
1 trackback
 

Comments

Leave a response

1. nukeedit
   Richard Cook said about 20 hours later:
   

   If someone’s ever iffy on closures, show them an example of a GUI with callback function on events like button press. Using anonymous functions with closures on common data variables, keeping everything in one place without making a one-off class, can be a thing of beauty.

2. nukeedit
   Josh Carter said 134 days later:
   

   Tom, thanks for the great example. Unlike many of the more academic discussions I’ve seen of closures, using logging as an example gives me something immediately useful to my day-to-day work. Now I’ve got some real motivation to better master closures.

3. nukeedit
   John said 134 days later:
   

   You can also view closures as a safer way of using global data. CS courses have taught us that using global data is bad, kind of like cheating. In your example, the closure routine uses data that actually lives in a ‘frame’ above – may as well be global.

   Global data is ‘bad’ because it is error prone. But as any student will tell you, it’s quite good as a way to express logic (otherwise they would not be so tempted to use it).

4. nukeedit
   Michael S. said 134 days later:
   

   I don’t think it would require too great a cortortion to use an object as the logger in this situation:

   logger = Logger.new("process", sn);
   logger.log("stage 1");
   # ...
   

   This could have some advantages too: if you want to log to say a file as well as stderr, say, you only need to change the Logger code.

   I guess I think of closures are mostly syntactic sugar: they can be mighty sweet, but you don’t get anything you can’t get with objects, particularly if you can define classes at runtime, as I think you can with ruby? (Closures are one-shot objects with only one method.)

5. nukeedit
   Dani Shorel said 134 days later:
   

   To answer Richard Cook, This is from the minimal wxLua example:

   frame:ConnectEvent(wx.wxID_ABOUT, wx.wxEVT_COMMAND_MENU_SELECTED, 
     function (event) 
       wx.wxMessageBox( 'This is the "About" dialog of the Minimal wxLua sample.', 
        "About wxLua", wx.wxOK + wx.wxICON_INFORMATION, frame )
   end )
   

6. nukeedit
   Tom Moertel said 134 days later:
   

   Michael S., what closures give you that one-shot objects don’t is implicit capturing of the context. For example, when f is defined below, it closes over x. The x inside of f is the same as the local x:

   x = 1
   f = lambda { x }
   puts f[] # prints 1
   x = 2
   puts f[] # prints 2
   

   On the other hand, if I had created an object and initialized it with x, the object would have had a copy of x’s current value, not an implicit connection to the local x variable itself. If x had changed, the object would not have stayed in sync:

   x = 1
   o = Struct.new(:x)[x]
   puts o.x  # prints 1
   x = 2
   puts o.x  # prints 1
   

   In the example I give in the article, this difference isn’t significant because sn doesn’t change over the course of processing a request, but for many kinds of programming this difference means closures will be more convenient than other options.

7. nukeedit
   joey said 134 days later:
   

   Just the article I needed! Could you write something similar on continuations? (I get that you can do exception handling with them, but that’s it.)

8. nukeedit
   Michael S. said 134 days later:
   

   Tom: doesn’t your example apply if (and only if) x is an integer? If it’s anything else at all it will be passed by reference to the constructor, and therefore modifiable outside the object/closure scope.

   i.e. if there was an Integer class, wouldn’t this work?

   x = Integer.new(1)
   o = Struct.new(:x)[x]
   puts o.x  # prints 1
   x.set(2)
   puts o.x  # prints 2
   

9. nukeedit
   Tom Moertel said 134 days later:
   

   Michael S., the point of closures is that they capture their environment – the local variables, the variables visible up the scope chain, and in the case of Ruby, the current value of self and possibly a locally captured block – so that when the code associated with the closure executes, it does so in the environment in which it was defined.

   As a programmer using closures, you don’t need to keep asking yourself, What information do I need to pass from the current environment into this block of code so that it can execute properly when the environment has gone away? All you need to do is define the code in the current environment, and the code’s closure will capture the environment automatically. When the code runs, its environment will magically be the environment in which it was defined – not a static snapshot but the real, live thing – and your code will have everything it needs, at no programming cost to you.

   In answer to your question, yes, you can take the relevant bits of the current environment and save references to them in an object or some other container and then refer to those saved bits later. (This is, in fact, what closures do behind the scenes.) But it takes effort to identify which bits are relevant, to save the bits, and possibly to refer to the saved bits. Closures eliminate this effort.

   Tom: doesn’t your example apply if (and only if) x is an integer?

   Actually it always works, regardless of what x holds. Your example, on the other hand, only works if (1) x holds a value whose type is always referred to by reference and (2) your code never changes x or o.x directly but only talks to the objects contained in these variables by sending messages.

   To continue your hypothetical example, if the following line:

   x.set(2)
   

   were changed to

   x = Integer.new(2)
   

   the connection between o’s x and the current environment’s x would be severed.

   Trying to capture environmental bits yourself takes effort and is subject to implementation error. When closures are free and get it right every time, why do it any other way?

   Cheers.

   —Tom

10. nukeedit
    beppegg said 477 days later:
    

    I think that this “environment capturing” actually breaks encapsulation (closure’s writer has to know that there will be exactly that context) and improves coupling (closure’s user has to provide a certain type of context).

    It’s a bit like using “global variables”.

    Maybe they can work well for local elaborations, but I can’t see how can they be applied to, for example, libraries construction.

    What do you think about this?

11. nukeedit
    Tom Moertel said 478 days later:
    

    @beppegg: I think you’re missing something important: a closure captures the environment in which it is defined, including scoping and visibility. When you call a function that has a closure, then, it will execute in the captured environment and won’t break any encapsulation unless you (the programmer) go out of your way to break it.

    In fact, one of the more celebrated uses of closures is to create encapsulation-preserving callback functions. These callbacks wrap around local, protected state in context so that it can be passed safely into the untrusted outside world within an opaque function that cannot be inspected or manipulated to reveal encapsulated details.

    Closures are great for writing libraries. Take a look, for example, at the GUI libraries written for languages that support closures; most of the event callbacks rely on closures.

12. nukeedit
    Orbimus said 980 days later:
    

    Wow! This is the best example of closures I’ve ever seen, thank you so much for making it clear on why these are so helpful:)

    Thanks again.

Trackbacks

Use the following link to trackback from your own site:
http://blog.moertel.com/articles/trackback/3

1. nukeedit
   From Coder's Eye
   On Closures
   Recently, I’ve been something of a language evangelist at work. I’ve been promoting the power and utility of Python and Javascript to both coworkers and management. One thing I’ve found difficult to get across to them is the concept.....

RSS feed for this post trackback uri

Your name	(leave url/email »)
Your blog
Your email
Your message
Comment Markup Help Preview comment