Re: Closures in Emacs and their usage scenarios.

[Emanuel Berg]

Hongyi Zhao wrote:

> I asked this question based on the following related
> concepts that I am currently considering: iterator,
> generator, recursor and closure (a decorator in Python is
> essentially a closure). According to the theory discussed by
> John McCarthy, it seems that the recursor or recursive
> Functions have a more important position in these concepts.
>
> http://www-formal.stanford.edu/jmc/recursive/recursive.html

Recursion is a darling of CS instructors because the code
often looks so neat (more mathematical/semantic) and it opens
up the doors to speak about such neat things as the base and
recursive case (maybe because it resembles the inductive
proofs of math, again)

OTOH iteration (i.e., loops) are considered a building block
of "imperative" programming, e.g. C, which in CS culture don't
rank as high as so-called functional programming
(Lisp/Erlang/Haskell etc), where, instead of side-effect
plagued iteration you have such things as tail recursion,
recursion over trees in both directions, and more ...

However in practice iteration is almost always better as it
don't place function after function on top of each other on
the stack, also iteration doesn't involve function call
overhead proportional to the scope of the problem solved, as
does recursion.

With Elisp in particular, which is considered slow in general
and even more so with respect to funcall overhead (this is
what I've heard from the Gnus people anyway, maybe to some
extent it is an excuse not ever to refactor Gnus insanely long
and complicated defuns, still I believe them) - so with Elisp
in particular don't do recursion, do iteration.

If you don't like the Elisp CL for loop (cl-loop for ... ) -
why BTW? I love it, and it has features the C for don't have,
for example multiple iterators - but if you don't like it (too
imperative/too explicit side effects or whatever reason) there
are other loops that looks as neat or neater than does
recursion ...

-- 
underground experts united
https://dataswamp.org/~incal