[R] 'closure' (was "stats:: spline's method could not be monoH.FC")

[Richard O'Keefe]

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 using 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 using 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.