Abby: Just one other thing. A friend of mine recommended reading the R-language manual which I haven't read in many years. I don't know if it's because I'm more expeRienced or just plain oldeR but I started it today and it's not nearly as daunting as I remember it being in the past. It's going to take me some time but I highly recommend checking it out if you haven't already. Maybe it's like a fine wine and just gets better with age !!!!!!! Good luck. Mark ---------- Forwarded message --------- From: Abby Spurdle <spurdle.a at gmail.com> Date: Sun, May 3, 2020 at 6:19 AM Subject: Re: [R] stats:: spline's method could not be monoH.FC To: Mark Leeds <markleeds2 at gmail.com> Cc: Martin Maechler <maechler at stat.math.ethz.ch>, Samuel Granjeaud IR/Inserm <samuel.granjeaud at inserm.fr>, r-help <r-help at r-project.org> Hi Mark, The article is good. However, there's still some grey areas. The documentation for base::typeof equates a closure with a function. However, the article defines a closure as a function together with an environment. A very minor difference I know, but it creates the problem that the word closure is used inconsistently. And that's without even getting into "frames". Equating a closure with a function (only), is perhaps misleading...??? Also, re-iterating I use function objects with attributes. (I prefer this approach, because I can make copies of function objects, and if necessary modify them). My guess is that doesn't meet the definition of an R closure (if you ignore the environment)...???, and it's unclear whether it meets the definition of a closure, more generally...??? So, I've still got the same problem, of how to refer to functions that have *either* attributes *or* environments, containing data. Maybe I should just stick to "Self-Referencing Function Objects" and "Functions Bundled with Data"...??? One last thing, the last time I read S4 documentation, I couldn't tell if it was possible to have S4-based function objects, and if so, could the body of the S4-based function object (while being called) access it's own slots...??? On Sun, May 3, 2020 at 4:27 PM Mark Leeds <markleeds2 at gmail.com> wrote:> > Abby: Here is an article on environments/closures which might be usefulto you. I was reviewing environments recently and it> was a clear explanation of how environments/closures work in R. Eventhough it's from 2000, I'm pretty certain that everything> said in it still holds.[[alternative HTML version deleted]]
Martin Maechler
2020-May-04 14:04 UTC
[R] 'closure' (was "stats:: spline's method could not be monoH.FC")
Just about this one some important term 'closure', hence I'm modifying the subject. Note we came here from my 2nd reason why I had added 'monoH.FC' feature only for splinefun() and not for spline() : - splinefun() is using's R feature of "(non-trivial) closure", i.e, it returns a *function* containing its own state ------------- Yes, there is some vagueness / ambiguity about how the term "closure" is used within R documentation and teaching : Yes, indeed, the term stems from lisp ("Scheme" more specifically according to https://en.wikipedia.org/wiki/Closure_(computer_programming) , but you should remember that R originally had been implemented as a "lisp with S-syntax" (that's my paraphrasing), see https://en.wikipedia.org/wiki/R_(programming_language) and (in the box on the right hand side) its list of "Influenced by" : Common Lisp, S, Scheme[2], XLispStat and [2] is Ross Ihaka's famous Interface paper : Ihaka, Ross (1998). R : Past and Future History (PDF) (Technical report). Statistics Department, The University of Auckland, Auckland, New Zealand. https://www.stat.auckland.ac.nz/~ihaka/downloads/Interface98.pdf And that's the reason why typeof(f) for all functions 'f' which are not primitive is "closure". All such functions (i.e. *not* the primitives) have an environment, as Mark Leeds explains, and what this means and why this is very important is beyond 'R-help'. Inside R's own C code, all such R functions are "closures", and programmers (incl R corers) who think more about the low level view of R objects would use the term like that ex 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 Now, most functions have only a "trivial environment" (my own terminology, when I'm teaching "advanced R" courses/classes, see https://github.com/mmaechler/ProgRRR/ for some teaching material) "trivial environment" meaning that their environment is - either the namespace belonging to the package the function is part of - or .GlobalEnv { which is the same as globalenv() } and most functions with non-trivial environment are just "helper" functions defined inside other functions which are very short lived (during the evaluation of the outer function's call). Now the remaining few functions with non-trivial environments that you see in "base R" are those returned by splinefun(), approxfun(), ecdf(), or stepfun() where the last two actually are implemented via approxfun(). -- -- -- I hope this has been useful "writeup" about 'closure' .. Best, Martin Martin Maechler ETH Zurich and R Core team
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...