Re: Closures in Emacs and their usage scenarios.

[Arthur Miller <arthur.miller@live.com>]

Hongyi Zhao <hongyi.zhao@gmail.com> writes:

> On Tue, Sep 28, 2021 at 7:53 PM Arthur Miller <arthur.miller@live.com> wrote:
>>
>> Stefan Monnier via Users list for the GNU Emacs text editor
>> <help-gnu-emacs@gnu.org> writes:
>>
>> >> I noticed the document on closure here [1] implemented in Emacs/Elisp currently.
>> >> But it's only a very concise and short introduction, and I want to
>> >> know more about the closures in Emacs and their usage scenarios.
>> >> Any helpful tips are welcome.
>> >
>> > Maybe a good starting point is
>> >
>> >     https://en.wikipedia.org/wiki/Closure_(computer_programming)
>>
>> Chapter 2 from "On Lisp" by P. Graham has also very nice and accessible intro to
>> functions and closures:
>>
>> https://sep.yimg.com/ty/cdn/paulgraham/onlisp.pdf?t=1595850613&
>>
>> So has also "Let Over Lambda" by D. Hoyte:
>>
>> https://letoverlambda.com/index.cl/guest/chap2.html
>>
>> Chapter 2 is an entire chapter on closures and using them; if one is not scared
>> by subtitles like: "Let Over Lambda Over Let Over Lambda" :).
>
> I have excerpted all relevant discussions as follows from there [1]:
>
> ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
> Let Over Lambda Over Let Over Lambda
>
> Users of object systems store values they want shared between all
> objects of a certain class into so-called class variables or static
> variables8. In lisp, this concept of sharing state between closures is
> handled by environments in the same way that closures themselves store
> state. Since an environment is accessible indefinitely, as long as it
> is still possible to reference it, we are guaranteed that it will be
> available as long as is needed.
>
> If we want to maintain a global direction for all counters, up to
> increment each closure's counter and down to decrement, then we might
> want to use a let over lambda over let over lambda pattern:
>
> (let ((direction 'up))
>   (defun toggle-counter-direction ()
>     (setq direction
>           (if (eq direction 'up)
>             'down
>             'up)))
>
>   (defun counter-class ()
>     (let ((counter 0))
>       (lambda ()
>         (if (eq direction 'up)
>           (incf counter)
>           (decf counter))))))
>
> In the above example, we have extended counter-class from the previous
> section. Now calling closures created with counter-class will either
> increment its counter binding or decrement it, depending on the value
> of the direction binding which is shared between all counters. Notice
> that we also take advantage of another lambda inside the direction
> environment by creating a function called toggle-counter-direction
> which changes the current direction for all counters.
>
> While this combination of let and lambda is so useful that other
> languages have adopted it in the form of class or static variables,
> there exist other combinations of let and lambda that allow you to
> structure code and state in ways that don't have direct analogs in
> object systems9. Object systems are a formalisation of a subset of let
> and lambda combinations, sometimes with gimmicks like inheritance
> bolted on10. Because of this, lisp programmers often don't think in
> terms of classes and objects. Let and lambda are fundamental; objects
> and classes are derivatives. As Steele says, the "object" need not be
> a primitive notion in programming languages. Once assignable value
> cells and good old lambda expressions are available, object systems
> are, at best, occasionally useful abstractions and, at worst,
> special-case and redundant.
> ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
>
> But TBF, these contents are still not so easy for me to understand.

I don't think you need to, to understand closures. What he says there is that
closures are more powerful than some other, more manistream tools used in
programming, particulary object orineted programming. To understand that you
would obviously you will need to have some udnerstanding of how object orinted
languages work, what are static class members, inheritance and so on, and you
would probably need to knoow it bit mroe than just how to use those. If you not
familiar with such topics I sugget to learn some Java and than try to udnerstand
that part later on.

My persoal opinion here is that the author is presenting closures as the basic
building block upon which to build other language primitives, and I think he is
showing us how simple basic concepts of Lisp are more universal than some other
concepts favoured by more popular languages. But that might be just mine
interpretation of that last part.