Abby Spurdle
2020-May-06 22:05 UTC
[R] 'closure' (was "stats:: spline's method could not be monoH.FC")
> 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. CookMartin, 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...
Richard O'Keefe
2020-May-07 02:47 UTC
[R] 'closure' (was "stats:: spline's method could not be monoH.FC")
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 <spurdle.a at 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 at 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.
Abby Spurdle
2020-May-07 03:27 UTC
[R] 'closure' (was "stats:: spline's method could not be monoH.FC")
> 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.What exactly do you mean? Are you implying that a user should not use environments? In which case, I would disagree.