4 ms·

Ok, sure, the author means "result of compiling a lambda expression". I think it's reasonable phrasing given that this is describing compiler transformations pr

• ScottBurson 11y ago
  My quibble is not really with the author, who knows what he's talking about. But I've seen lots of people using "closure" as if it were something in the source code.
  • ajuc 11y ago
    Is this an array? int xs[10]; Is this a function? int f(int x) { return 2*x; } I think it's overly pedantic to require people to say "function defined by this code".
    • ScottBurson 11y ago
      To a language implementor, these distinctions are not pedantic at all. A declaration of an array is a thing with a type, a name, and a size, each of which we have to pay attention to. It's really nothing like a sequence of consecutive locations in memory. To a language user, certainly, such distinctions usually don't matter. But conflating "lambda expression" and "closure" is particularly problematic. On the one hand, as this article points out, not all lambda expressions are evaluated by constructing closures. On the other, it's certainly not the case that all closures come from lambda expressions -- in many languages (certainly Scheme, Common Lisp, JavaScript, and Python, and I think Ruby and PHP) you can perfectly well create a closure from a named function; it's done all the time. Here's an example in Python: def f(a): def g(b): return a + b return g See? f returns a closure, but there's no lambda expression in the code. So given that lambda expressions and closures, though related, are not in 1-to-1 correspondence, I think it's important to understand the distinction.