RE: [External] : How to create a higher order function?

[Drew Adams]

> My question is: which of (B) and (C) is better?  (C) is definitely
> simpler, and with lexical scope becoming the default (perhaps at some
> point in time in the future) or the recommended (even now, I guess)
> setting, is probably the way to go.  But maybe (B) is better under some
> circumstances?  Is it faster?  (I don't think so, and my simple
> benchmarks were inconclusive.)  Is it more memory-efficient?  (Could
> be.)  Does it have any other advantage?

(C) is definitely better, in general.

(That's really the takeaway answer.)

The lexical environment, i.e., the one where
the function is defined, is the environment you
generally want for the function - it's, well,
the environment that _defines_ the function.

Generally speaking that's the only proper
environment for defining the function.  Of
course, this is Lisp, and nothing says you're
obliged to use the "proper", static, definition
of anything.
___

Two counter cases to (C), of sorts:

1. If you specifically want to allow other code
to be able to _change the behavior_ of the
function by simply providing an arbitrary
runtime value for some variable, then you might
want to dynamically bind that variable.

2. If a free variable in the function body is
never used _as a variable_, so that only its
_value_ at the point of the function definition
is needed, then you can do what you did, which
is to just substitute the value for the var.

This means there's no carrying around that var
binding in the closure, no need to look up its
value, etc.  But see next: that generally
doesn't mean a benefit in performance - the
contrary.

Wrt #2: Be aware that, at least with current
Elisp and its byte-compiler, #2 essentially
_loses_ the function definition at the point
where it's defined.  Instead, it substitutes
a _list_, a constructed lambda form, for the
function.  It's only later, in some other
context/environment, that that list can get
interpreted as a function.

Among other things, this means that that
representation of a function can't be compiled
as a function.  It can only be interpreted
(any number of times, in any contexts).

It can't in any way be treated or understood
by Emacs as a _function_ - it's just a list
with a lambda form, until it's eval'd.  Put
differently, it's just a _mention_ till it's
explicitly _used_.  It's a template function
definition, to be filled in and interpreted
as a function wherever and whenever.

On the other hand, for better and worse, it
can be treated as a list (it is one).  IOW,
instead of a function, you have essentially
the _name_, a representation, of a function.
If you want to do things to or with such a
representation, you can.  But this is rare.
___

Wrt the advantages and uses of dynamic binding
in the context of _Emacs_ - i.e., the reason
why Emacs has, and should continue to have,
dynamic binding (along with lexical binding),
see RMS's arguments here:

https://www.gnu.org/software/emacs/emacs-paper.html#SEC17

https://www.gnu.org/software/emacs/emacs-paper.html#SEC18

Those arguments are as valid today (& tomorrow)
as they were when written in 1981.

Wrt the uses and behavior of dynamic & lexical
binding in _Lisp_ (not particular to Emacs), I
recommend reading the relevant parts of "Common
Lisp The Language".

https://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node43.html

Here's my SO post on reading that section in
relation to Emacs:

https://stackoverflow.com/a/7135315/729907