3 ms·

Wait, what? A closure can be a lambda and a lambda can be a closure, but you can have closures that aren't lambdas and lambdas that aren't closures. Why link th

by cwyers 10y ago

Wait, what? A closure can be a lambda and a lambda can be a closure, but you can have closures that aren't lambdas and lambdas that aren't closures. Why link them together at all? "A closure with an empty environment" is only a lambda if it's unnamed, otherwise it's just a function.

kibwen 10y ago
I think the burden of proof is the opposite: why not link them together? What are the benefits of having closures and lambdas be two distinct language features when having just one seems to suffice (specifically, having a lambda be a degenerate closure)? As for naming, that's an orthogonal issue, as a closure can be anonymous just as easily, and I see no use in drawing a semantic distinction between anonymous "lambdas" and nonymous "functions".
- cwyers 10y ago
  What on earth are you talking about? The definition of "lambda" is "anonymous function." Naming is orthogonal to closures, yes, but it's the entire difference between a lambda and any other kind of function. A lambda can close over state or not, it doesn't matter. It just needs to not have a name. So if naming is orthogonal to closures, then lambdas are orthogonal to closures, and then it makes no sense to compare them.
  - kibwen 10y ago
    > The definition of "lambda" is "anonymous function." > A lambda can close over state or not, it doesn't matter. I've never heard of any definition of "function" that allows closing over state, that's the demarcation that we use to distinguish a function from a closure. What taxonomy are you trying to propose? And going back to my original question, what is the practical intent of trying to make a lambda a semantically-distinct concept from a closure?
    - cwyers 10y ago
      https://wiki.haskell.org/Anonymous_function https://wiki.haskell.org/Anonymous_function https://wiki.haskell.org/Closure https://wiki.haskell.org/Closure
    - Dylan16807 10y ago
      In the phrase "anonymous function", "function" means anything that you can call. This includes closures. I'm very surprised you've never heard of the word "function" being used that way.

by cwyers 10y ago

kibwen 10y ago

I think the burden of proof is the opposite: why not link them together? What are the benefits of having closures and lambdas be two distinct language features when having just one seems to suffice (specifically, having a lambda be a degenerate closure)? As for naming, that's an orthogonal issue, as a closure can be anonymous just as easily, and I see no use in drawing a semantic distinction between anonymous "lambdas" and nonymous "functions".

cwyers 10y ago
What on earth are you talking about? The definition of "lambda" is "anonymous function." Naming is orthogonal to closures, yes, but it's the entire difference between a lambda and any other kind of function. A lambda can close over state or not, it doesn't matter. It just needs to not have a name. So if naming is orthogonal to closures, then lambdas are orthogonal to closures, and then it makes no sense to compare them.
- kibwen 10y ago
  > The definition of "lambda" is "anonymous function." > A lambda can close over state or not, it doesn't matter. I've never heard of any definition of "function" that allows closing over state, that's the demarcation that we use to distinguish a function from a closure. What taxonomy are you trying to propose? And going back to my original question, what is the practical intent of trying to make a lambda a semantically-distinct concept from a closure?
  - cwyers 10y ago
    https://wiki.haskell.org/Anonymous_function https://wiki.haskell.org/Anonymous_function https://wiki.haskell.org/Closure https://wiki.haskell.org/Closure
  - Dylan16807 10y ago
    In the phrase "anonymous function", "function" means anything that you can call. This includes closures. I'm very surprised you've never heard of the word "function" being used that way.