Hacker News Reader

Comment by ScottBurson | Hacker News Reader

Yes, this has been one of my pet peeves for a while too. Everybody: a closure, as the parent says, is an implementation construct. It is not something you can find in your source code. The syntactic construct -- the thing you write in your code -- is called a lambda expression. Not a "lambda function", and not a "closure"!

Lambda expressions are to closures as `new' expressions are to instances: a lambda expression evaluates to a closure, and a `new' expression evaluates to an instance. Since any expression can be evaluated multiple times, in general the relationship is one-to-many: a lambda expression can be evaluated N times to produce N closures, just as a `new' expression can be evaluated N times to produce N instances.

(Instances and closures are closely related: an instance is a piece of state with several operations that can be invoked on it, while a closure is a piece of state with one operation that can be invoked on it.)

View on HN

Your insistence on a specific meaning for the words ignores how words are actually used: overloaded based on context. If I call these things 'closures', you understand I'm talking about the 'lambda expressions' and not the implementation construct.

  class Foo
  end

There, a class object. Oh sorry, an object is an implementation construct; what you have there is an expression that produces an object... <- that is unhelpful semantic squabbling. It's highly inconvenient to use such indirect language. This is the view of a class object that I have most of the time and a 'lambda expression' is the view I have of a closure most of the time.

If I see the Eiffel tower, I say: look, the Eiffel tower. Not: look, an image of the Eiffel tower, with some details obscured by clouds and smoke and without considering any of the construction details and history that are an essential part of the Eiffel tower. For all practical purposes of communication, it's the Eiffel tower.

That's not a fair example. There are languages that have lambda expressions but not the lexical scope that requires closures, whereas there are no languages that have class definition expressions but not classes.

Given there is a meaningful distinction to be made, insistence on accurate terminology becomes a lot more reasonable.

> Instances and closures are closely related: an instance is a piece of state with several operations that can be invoked on it, while a closure is a piece of state with one operation that can be invoked on it.

I would go further, and say that they're equivalent—that "one operation" can be a dispatch function:

    def make_object
      x = 5
      lambda do |m|
        case m
        when 'increment'
          x += 1
        when 'decrement'
          x -= 1
        when 'get'
          x
        end
      end
    end

    o = make_object
    o.call('get')       # => 5
    o.call('increment') # => 6
    o.call('decrement') # => 5

In fact, in SICP, they build their object system in this way, if my memory serves me correctly.

Of course. Closures are, after all, a poor man's objects[1].

[1] http://codermonk.blogspot.com/2007/01/venerable-master-qc-na...

That's a really good explanation.

Reply on news.ycombinator.com