[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Closures in Emacs and their usage scenarios.

From: Hongyi Zhao
Subject: Re: Closures in Emacs and their usage scenarios.
Date: Thu, 30 Sep 2021 08:59:13 +0800

On Thu, Sep 30, 2021 at 6:11 AM Tomas Hlavaty <> wrote:
> On Wed 29 Sep 2021 at 08:28, Stefan Monnier <> 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 <> 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

What's the exact meaning of "the same fringe problem"?

> and possible solutions.  It is worth the time and effort.

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 [1], it seems that the recursor or
recursive Functions have a more important position in these concepts.


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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]