A closure is a function plus an environment. That's it. This is a sixty-year-old thing in programming languages.
A closure is a dynamic value representing an instance of a function in a particular context which it can refer to. When a program in Algol 60 passed a procedure P to a procedure Q, what it passed was logically a pair consisting of a pointer to the executable code of P and a pointer to the context P was declared in, often called the static link. This was nothing other than a closure. The limit in Algol 60 was that contexts were not retained, they formed a pure stack. So all you could do with a procedure parameter was call it or pass it on. Same thing in Pascal and other Algol-like languages. Modern functional languages retain just as much of the context as the function can actually refer to. My Smalltalk compiler, for example, classifies variables as - only the value needs to be kept - the variable needs to be retained *as* a variable - not used in a nested function R doesn't have that luxury, because R is rather more dynamic and allows environments to be inspected. For most practical purposes, there is simply no point in bothering to distinguish "function" and "closure" in R. The only functions that are not closures are primitives. But you can call args(f), body(f), and environment(f) on any function, whether it is a closure or a primitive. If you want to mess around with the environment of a function, then you need to understand this stuff, but you probably shouldn't do that. On Thu, 7 May 2020 at 10:06, Abby Spurdle <spurdl...@gmail.com> wrote: > > > OTOH, Hadley Wickham has written a book "Advanced R" which has been > > the best book about advanced R by far (in my view, notably > > before it morphed (towards the 2nd edition) to use more and more > > non-base R packages). There, he used "Closure" in a different, > > stricter sense, starting the section 'Closures' with > > βAn object is data with functions. > > A closure is a function with data.β β John D. Cook > > Martin, Thank you, > > I've reviewed everything, and I've come to the following conclusion: > In general, a self-referencing function is not a closure, as such; and > In general, a closure is not a self-referencing function, as such. > > So, to describe the superset, maybe I should say something like: > > *Self-Referencing Functions and Closures* > > Also, I support multi-paradigm programming, including some global > state data mainly for default formatting-related options. > But if I understand things correctly, you support (or at least have > some preference for) purely-functional programming. > Which is one area, where we diverge. > > It seems to me, the most people who advocate closures prefer > purely-functional programming. > > If we use the principle, that in purely-functional programming, the > output of a function is not dependent on mutable state data, then > wouldn't it be better to say something like: > > A closure is a function with (preferably non-mutable) data. > > > P.S. > If anyone's interested in creating R functions that reference > themselves, look at: > base::sys.function > > Also, my package intoo contains convenience functions (THIS, THAT and > THEN), that wrap sys.function, giving it a slightly more > object-oriented flavor, and explore this idea further. > However, re-reading my documentation, I note that my examples need > some improvement... > > ______________________________________________ > R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see > https://stat.ethz.ch/mailman/listinfo/r-help > PLEASE do read the posting guide http://www.R-project.org/posting-guide.html > and provide commented, minimal, self-contained, reproducible code. ______________________________________________ R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide http://www.R-project.org/posting-guide.html and provide commented, minimal, self-contained, reproducible code.
