Re: Closures in Emacs and their usage scenarios.

[Hongyi Zhao <hongyi.zhao@gmail.com>]

On Thu, Sep 30, 2021 at 6:11 AM Tomas Hlavaty <tom@logand.com> wrote:
>
> 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

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.

[1] http://www-formal.stanford.edu/jmc/recursive/recursive.html


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