Re: Closures in Emacs and their usage scenarios.

[Tomas Hlavaty <tom@logand.com>]

On Wed 29 Sep 2021 at 08:28, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
> Tomas Hlavaty [2021-09-29 08:10:36] wrote:
>> On Wed 29 Sep 2021 at 00:04, Stefan Monnier via Users list for the GNU Emacs
>> text editor <help-gnu-emacs@gnu.org> wrote:
>>> And captured variables that are mutated are also quite rare
>> I don't think so.
>
> How rare can depend on the language (as mentioned: they are completely
> absent from Haskell/OCaml and friends),

The topic is: Closures in Emacs and their usage scenarios.

In Emacs Lisp, closures mutating captured variables might be rare now
because lexical scoping arrived recently.

But it opens a new world of possibilities worth learning about.
It should be encouraged.
Many usage scenarios could be seen in Common Lisp and Scheme.

There are examples in the Emacs code base already, see thunk-delay, for
example.

>> The best thing about closures is that they allow wrapping state
>> mutations under simple interface of funcall.

The toggle-counter-direction is an interesting example.

Next step could be showing the wonderful concept of generators;
brilliantly shown, for example, in a solution of the same fringe
problem.  Once one understands this, it is a great way of creating light
weight streams on the spot.  It is also a robust solution to off-by-one
errors often caused by complexities of indexing in complex loops.

@Hongyi Zhao: learn about the same fringe problem and possible
solutions.  It is worth the time and effort.

> but in my experience in ELisp they're the exception rather than the
> rule

Because closures and dynamic binding does not go together well.
Luckily, that is changing now and closures became relevant in ELisp.

> Note also that such mutated+captured variables are more costly (at
> least in the most prevalent way to implement closures).

The cost is mostly theoretical and usually irrelevant for practical
purposes.  I would say on the contrary, the code can be simpler, more
readable and robust and easier to optimize than alternatives.

There is lots of work being done on ELisp compilation, so the future
seems bright.  Maybe representing the captured variables as an alist is
more costly than if it was an array?  (For example, I never had a
performance issue with closures mutating captured variables in sbcl.)
In any case, optimizing this is not really a high priority issue I
think.