3 ms·

> A closure is like an anonymous function. I like the article overall, but I have a bit of a pedantic note about this opening line. Using "like" suggests that

> A closure is like an anonymous function. I like the article overall, but I have a bit of a pedantic note about this opening line. Using "like" suggests that there is some similarity that can be used to understand one thing from the other, but in truth these are two distinct (though related) technical terms, and I think phrasing this relationship as a simile may actually obstruct understanding rather than enable it. An anonymous function is just a function without a name. There's nothing particularly exciting about that, except that they only really make sense as a concept within the context of a language with first-class functions (i.e., a language where functions are values that can be passed around as arguments and such). A closure is a function paired with an environment. Technically (meaning "in the academic literature"), this can be any function at all --- named functions can be used to create closures. But in Rust this is not the case, since they only use the term in connection with anonymous functions. This is actually addressed in the first couple of lines of the Rust Book's entry on closures [1]. Saying "a closure is like an anonymous function" would be like me saying "a car is like a set of four wheels". While it is true that the four wheels are integral to the car's identity, it is not the case that these things are directly similar in the way that the word "like" suggests they are. [1] https://doc.rust-lang.org/book/ch13-01-closures.html https://doc.rust-lang.org/book/ch13-01-closures.html

jerf 3y ago
I would further elaborate on your point by saying that as someone who likes to hang out on programming fora and help people as I was helped when I was young, this terminology confusion causes real confusion in the field as well. Many programmers-in-training find it confusing as to why whether or not a function has a name seems to be tied to whether or not it has an environment (not that they phrase it that way but that's what it boils down to), and my usual answer is to explain something much like your post; the resolution is, there is no such connection. I have fielded this question in one form or another many times. "Anonymous function" should not be used as a synonym for "closure". Generally I will follow along with the dominant language terminology if I am clearly in the context of a very particular language, but may include why I don't like the language community's terminology if it helps my point.
- DonaldPShimoda 3y ago
  Oh absolutely, it's one of many such conflations that are common among the majority of real-world programmers. And you're right that a big part of the problem is poorly written (or sometimes just incorrect!) language documentation that doesn't go to the appropriate lengths to explain the distinctions in the terms. Some other conflations I see frequently in the PL space: - "argument" vs "parameter" - "type coercion" vs "type casting" - "static typing" vs "strong typing" - "function" vs "method" (and we can throw in "procedure" and "subroutine")
sfvisser 3y ago
In some language all functions capture their environment, making that original statement more true than you make it out to be. Personally I think the term closure should be banned, because it only adds confusion. There are just functions, some named some anonymous, some capturing the environment, some not, some being disallowed by some constraints from the host language. The term closure cuts through this space in a useless and rather ad-hoc way.
- dllthomas 3y ago
  I don't think it's ad-hoc so much as implementation focused.
- DonaldPShimoda 3y ago
  > In some language all functions capture their environment In some pieces of art all quadrilaterals are squares, but this doesn't mean the two terms are somehow equivalent and therefore one of the terms should be done away with. There is a consistent technical distinction between "functions" and "closures". > There are just functions, some named some anonymous, some capturing the environment, some not No. Functions do not capture environments. Functions don't know what environments are. If you're talking about functions and environments together, you're talking about closures. That's really all there is to it.
  - untitaker_ 3y ago
    I agreed with your original comment but this insistence on "functions never capture environments" is not useful when a really large portion of programmers come from those kinids of languages and are trying to learn Rust. You can insist on correct terminology or adapt to your surroundings and try to speak the language of your target audience. I assume somebody who calls closures "anonymous functions" is speaking as a JavaScript developer to JavaScript developers. Even if not, it's not unreasonable to adopt the terminology of such a popular language.
    - DonaldPShimoda 3y ago
      The "problem" with your perspective, as I see it, is that it is not I who is entering a context. Rather, it is other people who are trying to learn about programming language theory and design; they are entering my context. So it's not up to them what the terms mean, really. The terms have established meanings. It is true that a lot of language communities conflate terms, and this is especially prevalent among the people who are hobbyists and amateurs in the space --- an important community, to be sure! But not a group of people who are already knowledgeable. When people from the lay community of Language X choose to get involved in the community of Language Y or, more importantly, the community of programming languages research, they often encounter friction because suddenly these terms that they previously believed to be synonymous actually have very distinct technical meanings. So that is why I try to address these conflations when I see them. That said, I do make a point to state up-front that my notes are pedantic, because I know not everybody cares to learn about such things, and that's perfectly fine! But I will continue writing corrections when I see them, though I try hard to make my corrections kind in nature.

jerf 3y ago

I would further elaborate on your point by saying that as someone who likes to hang out on programming fora and help people as I was helped when I was young, this terminology confusion causes real confusion in the field as well. Many programmers-in-training find it confusing as to why whether or not a function has a name seems to be tied to whether or not it has an environment (not that they phrase it that way but that's what it boils down to), and my usual answer is to explain something much like your post; the resolution is, there is no such connection. I have fielded this question in one form or another many times. "Anonymous function" should not be used as a synonym for "closure". Generally I will follow along with the dominant language terminology if I am clearly in the context of a very particular language, but may include why I don't like the language community's terminology if it helps my point.

DonaldPShimoda 3y ago
Oh absolutely, it's one of many such conflations that are common among the majority of real-world programmers. And you're right that a big part of the problem is poorly written (or sometimes just incorrect!) language documentation that doesn't go to the appropriate lengths to explain the distinctions in the terms. Some other conflations I see frequently in the PL space: - "argument" vs "parameter" - "type coercion" vs "type casting" - "static typing" vs "strong typing" - "function" vs "method" (and we can throw in "procedure" and "subroutine")

sfvisser 3y ago

In some language all functions capture their environment, making that original statement more true than you make it out to be. Personally I think the term closure should be banned, because it only adds confusion. There are just functions, some named some anonymous, some capturing the environment, some not, some being disallowed by some constraints from the host language. The term closure cuts through this space in a useless and rather ad-hoc way.

dllthomas 3y ago
I don't think it's ad-hoc so much as implementation focused.
DonaldPShimoda 3y ago
> In some language all functions capture their environment In some pieces of art all quadrilaterals are squares, but this doesn't mean the two terms are somehow equivalent and therefore one of the terms should be done away with. There is a consistent technical distinction between "functions" and "closures". > There are just functions, some named some anonymous, some capturing the environment, some not No. Functions do not capture environments. Functions don't know what environments are. If you're talking about functions and environments together, you're talking about closures. That's really all there is to it.
- untitaker_ 3y ago
  I agreed with your original comment but this insistence on "functions never capture environments" is not useful when a really large portion of programmers come from those kinids of languages and are trying to learn Rust. You can insist on correct terminology or adapt to your surroundings and try to speak the language of your target audience. I assume somebody who calls closures "anonymous functions" is speaking as a JavaScript developer to JavaScript developers. Even if not, it's not unreasonable to adopt the terminology of such a popular language.
  - DonaldPShimoda 3y ago
    The "problem" with your perspective, as I see it, is that it is not I who is entering a context. Rather, it is other people who are trying to learn about programming language theory and design; they are entering my context. So it's not up to them what the terms mean, really. The terms have established meanings. It is true that a lot of language communities conflate terms, and this is especially prevalent among the people who are hobbyists and amateurs in the space --- an important community, to be sure! But not a group of people who are already knowledgeable. When people from the lay community of Language X choose to get involved in the community of Language Y or, more importantly, the community of programming languages research, they often encounter friction because suddenly these terms that they previously believed to be synonymous actually have very distinct technical meanings. So that is why I try to address these conflations when I see them. That said, I do make a point to state up-front that my notes are pedantic, because I know not everybody cares to learn about such things, and that's perfectly fine! But I will continue writing corrections when I see them, though I try hard to make my corrections kind in nature.