Closures in Emacs and their usage scenarios.

Closures in Emacs and their usage scenarios.

[Hongyi Zhao]

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.

[1] https://www.gnu.org/software/emacs/manual/html_node/elisp/Closures.html

Regards
-- 
Assoc. Prof. Hongyi Zhao <hongyi.zhao@gmail.com>
Theory and Simulation of Materials
Hebei Vocational University of Technology and Engineering
No. 473, Quannan West Street, Xindu District, Xingtai, Hebei province

Re: Closures in Emacs and their usage scenarios.

[Emanuel Berg via Users list for the GNU Emacs text editor]

Hongyi Zhao wrote:

> 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.
>
> [1] https://www.gnu.org/software/emacs/manual/html_node/elisp/Closures.html

As a part of the language, or perhaps how the language is
implemented, I can't say I understand it, but from the
Joe Hacker perspective it is understandable enough, it can be
used so a function (or set of functions) will have a memory
and can use the variables that are part of that memory like
global variables, even tho they aren't and are protected from
outside interference, so that, for example, they wont be reset
between function calls ...

Here is one example - note that the byte-compiler will warn
that "the function ‘align-from-left’ is not known to be
defined." Well, OK.

There is a better/easier example, an example with a counter,
and then three functions within the `let' body, the let holds
the counter value and the functions are "increase", "decrease",
and "reset". Maybe one wants a "print" function as well? OK,
so four functions.

ikr? smells like OO spirit ...

;;; -*- lexical-binding: t -*-
;;;
;;; this file:
;;;   https://dataswamp.org/~incal/emacs-init/align-from-left.el

(require 'cl-lib)

(let ((alf-regexp))
  (defun align-from-left (&optional set-regexp)
    (interactive "p")
    (let ((default-regexp "^\\|[[:punct:]]\\|[[:space:]][[:alnum:]]"))
      (unless (stringp set-regexp)
        (cl-case set-regexp
          ( 4 (setq alf-regexp (read-regexp "regexp: ")))
          (16 (setq alf-regexp default-regexp))
          ( t (unless alf-regexp
                (setq alf-regexp default-regexp) )))))
    (let ((beg (point))
          (re  (or (and (stringp set-regexp) set-regexp)
                    alf-regexp) ))
      (when (re-search-backward re (line-beginning-position) t)
        (while (looking-at "[[:space:]]")
          (forward-char 1) )
        (insert (make-string (- beg (point)) ?\s)) ))))
(defalias 'alf #'align-from-left)

(provide 'align-from-left)

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

Re: Closures in Emacs and their usage scenarios.

[Emanuel Berg via Users list for the GNU Emacs text editor]

> (let ((alf-regexp))
>   (defun align-from-left (&optional set-regexp)
>     (interactive "p")
>     (let ((default-regexp "^\\|[[:punct:]]\\|[[:space:]][[:alnum:]]"))
>       (unless (stringp set-regexp)
>         (cl-case set-regexp
>           ( 4 (setq alf-regexp (read-regexp "regexp: ")))
>           (16 (setq alf-regexp default-regexp))
>           ( t (unless alf-regexp
>                 (setq alf-regexp default-regexp) )))))
>     (let ((beg (point))
>           (re  (or (and (stringp set-regexp) set-regexp)
>                     alf-regexp) ))
>       (when (re-search-backward re (line-beginning-position) t)
>         (while (looking-at "[[:space:]]")
>           (forward-char 1) )
>         (insert (make-string (- beg (point)) ?\s)) ))))

Hm, looking at the code now I don't really understand what
that regular expression

  "^\\|[[:punct:]]\\|[[:space:]][[:alnum:]]"

is supposed to say ... but the program seems to work as
intended.

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

Re: Closures in Emacs and their usage scenarios.

[Stefan Monnier via Users list for the GNU Emacs text editor]

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


-- Stefan

RE: [External] : Re: Closures in Emacs and their usage scenarios.

[Drew Adams]

[-- Attachment #1: Type: text/plain, Size: 532 bytes --]

> > I want to know more about the closures in Emacs
> 
> Maybe a good starting point is
> wikipedia.org/wiki/Closure_(computer_programming)

Yes.  Here's another (closures in Lisp, not Emacs).

https://www.youtube.com/watch?v=aAlR3cezPJg

This is Scheme in Scheme.  But same idea.

You can show the full transcript (click "..." below
the video on the page), and search it for "closure",
if you like (11:42, 12:45, 19:10, 20:10, 45:52,
46:30, 47:07, 48:33, 48:57, 49:17).  But for more
fun, start at the beginning...

[-- Attachment #2: winmail.dat --]
[-- Type: application/ms-tnef, Size: 13506 bytes --]

Re: [External] : Re: Closures in Emacs and their usage scenarios.

[Emanuel Berg via Users list for the GNU Emacs text editor]

Drew Adams wrote:

> This is Scheme in Scheme.  But same idea.

It is Scheme in Scheme haha :)

Maybe they are even present in Clojure BTW ...

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

Re: Closures in Emacs and their usage scenarios.

[Hongyi Zhao]

On Tue, Sep 28, 2021 at 10:50 AM Emanuel Berg via Users list for the
GNU Emacs text editor <help-gnu-emacs@gnu.org> wrote:
>
> Hongyi Zhao wrote:
>
> > 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.
> >
> > [1] https://www.gnu.org/software/emacs/manual/html_node/elisp/Closures.html
>
> As a part of the language, or perhaps how the language is
> implemented, I can't say I understand it, but from the
> Joe Hacker perspective it is understandable enough, it can be
> used so a function (or set of functions) will have a memory
> and can use the variables that are part of that memory like
> global variables, even tho they aren't and are protected from
> outside interference, so that, for example, they wont be reset
> between function calls ...
>
> Here is one example - note that the byte-compiler will warn
> that "the function ‘align-from-left’ is not known to be
> defined." Well, OK.
>
> There is a better/easier example, an example with a counter,
> and then three functions within the `let' body, the let holds
> the counter value and the functions are "increase", "decrease",
> and "reset". Maybe one wants a "print" function as well? OK,
> so four functions.
>
> ikr? smells like OO spirit ...

What's the meaning of `OO spirit'?

>
> ;;; -*- lexical-binding: t -*-
> ;;;
> ;;; this file:
> ;;;   https://dataswamp.org/~incal/emacs-init/align-from-left.el
>
> (require 'cl-lib)
>
> (let ((alf-regexp))
>   (defun align-from-left (&optional set-regexp)
>     (interactive "p")
>     (let ((default-regexp "^\\|[[:punct:]]\\|[[:space:]][[:alnum:]]"))
>       (unless (stringp set-regexp)
>         (cl-case set-regexp
>           ( 4 (setq alf-regexp (read-regexp "regexp: ")))
>           (16 (setq alf-regexp default-regexp))
>           ( t (unless alf-regexp
>                 (setq alf-regexp default-regexp) )))))
>     (let ((beg (point))
>           (re  (or (and (stringp set-regexp) set-regexp)
>                     alf-regexp) ))
>       (when (re-search-backward re (line-beginning-position) t)
>         (while (looking-at "[[:space:]]")
>           (forward-char 1) )
>         (insert (make-string (- beg (point)) ?\s)) ))))
> (defalias 'alf #'align-from-left)
>
> (provide 'align-from-left)
>
> --
> underground experts united
> https://dataswamp.org/~incal
>
>


-- 
Assoc. Prof. Hongyi Zhao <hongyi.zhao@gmail.com>
Theory and Simulation of Materials
Hebei Vocational University of Technology and Engineering
No. 473, Quannan West Street, Xindu District, Xingtai, Hebei province

Re: Closures in Emacs and their usage scenarios.

[Eduardo Ochs]

Hi Hongyi,

There are some snippets and links here:

  http://angg.twu.net/eev-intros/find-lexical-intro.html

If your brain is wired like mine is then you will find the examples
there - especially the ones in section 3 - great for getting a clear
mental image of what closures are and how they are implemented in
Emacs. You will need eev to run the examples.

  Cheers,
    Eduardo Ochs
    http://angg.twu.net/#eev


On Mon, 27 Sept 2021 at 06:43, Hongyi Zhao <hongyi.zhao@gmail.com> wrote:
>
> 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.
>
> [1] https://www.gnu.org/software/emacs/manual/html_node/elisp/Closures.html
>
> Regards
> --
> Assoc. Prof. Hongyi Zhao <hongyi.zhao@gmail.com>
> Theory and Simulation of Materials
> Hebei Vocational University of Technology and Engineering
> No. 473, Quannan West Street, Xindu District, Xingtai, Hebei province
>

Re: Closures in Emacs and their usage scenarios.

[Emanuel Berg via Users list for the GNU Emacs text editor]

Eduardo Ochs wrote:

> If your brain is wired like mine is then you will find the
> examples there - especially the ones in section 3 - great
> for getting a clear mental image of what closures are and
> how they are implemented in Emacs. You will need eev to run
> the examples.

If your mind is wired like mine you would either yank the part
that you liked and mentioned here, or call it something
different than "section 3" which renders no hits when I search
for it on that page ...

(But perhaps it is a good thing that not all people are wired
the same way. What a horrible world that would be.)

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

Re: Closures in Emacs and their usage scenarios.

[Eduardo Ochs]

On Tue, 28 Sept 2021 at 04:26, Emanuel Berg via Users list for the GNU
Emacs text editor <help-gnu-emacs@gnu.org> wrote:
>
> If your mind is wired like mine you would either yank the part
> that you liked and mentioned here, or call it something
> different than "section 3" which renders no hits when I search
> for it on that page ...

Hi Emanuel,

I've been trying to make eev accessible to people who can only play
with it 5 minutes per week, but I don't know how to reduce these 5
minutes to far less than that... =(

To find Section 3 in that page, try this:

  http://angg.twu.net/eev-intros/find-lexical-intro.html#3

Hope it helps,
  E.

Re: Closures in Emacs and their usage scenarios.

[Hongyi Zhao]

On Tue, Sep 28, 2021 at 3:11 PM Eduardo Ochs <eduardoochs@gmail.com> wrote:
>
> Hi Hongyi,
>
> There are some snippets and links here:
>
>   http://angg.twu.net/eev-intros/find-lexical-intro.html
>
> If your brain is wired like mine is then you will find the examples
> there - especially the ones in section 3 - great for getting a clear
> mental image of what closures are and how they are implemented in
> Emacs. You will need eev to run the examples.

Thank you so much for letting me know about your wonderful and
interesting project. I installed it by straight with its use-package
integration feature enabled [1]:

(use-package eev
  :straight (:host github :repo "edrx/eev"))

[1] https://github.com/raxod502/straight.el#integration-with-use-package


>   Cheers,
>     Eduardo Ochs
>     http://angg.twu.net/#eev

Best, HZ

Re: Closures in Emacs and their usage scenarios.

[Emanuel Berg via Users list for the GNU Emacs text editor]

Hongyi Zhao wrote:

>> smells like OO spirit ...
>
> What's the meaning of `OO spirit'?

OO = Object Oriented

The best definition of OOP that I've heard is the coupling of
data and the functions ("methods" in OO lingo) that act upon
that data. What I can see that's exactly what happens here
with closures ... (or at least the examples I provided are
like that)

OO was huge in the 90s when some programs were even rewritten
just so they would be "OO" as well. Today, not even the C++
guys stress the OO component of their language - instead they
think C++ is great for other reasons.

From the Python people there were also a huge OO enthusiasm
(Python is from 1991, C++ is as old as from 1983) where even
the language itself was OO - maybe you can tell me/us, if the
OO enthusiasm has quieted down there as well ...

"Smells Like Teen Spirit" is a 1991 Nirvana song from the
album Nevermind.
<https://www.youtube.com/watch?v=hTWKbfoikeg>

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

Re: Closures in Emacs and their usage scenarios.

[Hongyi Zhao]

On Tue, Sep 28, 2021 at 4:31 PM Emanuel Berg via Users list for the
GNU Emacs text editor <help-gnu-emacs@gnu.org> wrote:
>
> Hongyi Zhao wrote:
>
> >> smells like OO spirit ...
> >
> > What's the meaning of `OO spirit'?
>
> OO = Object Oriented
>
> The best definition of OOP that I've heard is the coupling of
> data and the functions ("methods" in OO lingo) that act upon
> that data. What I can see that's exactly what happens here
> with closures ... (or at least the examples I provided are
> like that)
>
> OO was huge in the 90s when some programs were even rewritten
> just so they would be "OO" as well. Today, not even the C++
> guys stress the OO component of their language - instead they
> think C++ is great for other reasons.
>
> From the Python people there were also a huge OO enthusiasm
> (Python is from 1991, C++ is as old as from 1983) where even
> the language itself was OO - maybe you can tell me/us, if the
> OO enthusiasm has quieted down there as well ...

Lisp in nature is OO and can be nothing or anything. From this point
of view, lisp in itself maybe not considered as a language - it is
only a method and philosophy of constructing all things, and even can
reconstruct itself. Just as the praise by Bob Kanefsky and Julia
Ecklar in "Eternal Flame" [1]:

And God wrote in Lisp code every creature great and small.
Don't search the disk drive for man.c, when the listing's on the wall.
And when I watch the lightning burn unbelievers to a crisp,
I know God had six days to work. So he wrote it all in Lisp.

[1] https://www.gnu.org/fun/jokes/eternal-flame.en.html

> "Smells Like Teen Spirit" is a 1991 Nirvana song from the
> album Nevermind.
> <https://www.youtube.com/watch?v=hTWKbfoikeg>
>
> --
> underground experts united
> https://dataswamp.org/~incal

HZ

Re: Closures in Emacs and their usage scenarios.

[tomas]

[-- Attachment #1: Type: text/plain, Size: 573 bytes --]

On Tue, Sep 28, 2021 at 04:54:23PM +0800, Hongyi Zhao wrote:

[...]

> And God wrote in Lisp code every creature great and small.
> Don't search the disk drive for man.c, when the listing's on the wall.
> And when I watch the lightning burn unbelievers to a crisp,
> I know God had six days to work. So he wrote it all in Lisp.
> 
> [1] https://www.gnu.org/fun/jokes/eternal-flame.en.html

But before you get too carried away, there's this: https://xkcd.com/224/

;-P

Cheers

(yes, I know you were just quoting; besides, I'm a fan of
Lisp, too)

 - t

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: Closures in Emacs and their usage scenarios.

[Hongyi Zhao]

On Tue, Sep 28, 2021 at 6:40 PM <tomas@tuxteam.de> wrote:
>
> On Tue, Sep 28, 2021 at 04:54:23PM +0800, Hongyi Zhao wrote:
>
> [...]
>
> > And God wrote in Lisp code every creature great and small.
> > Don't search the disk drive for man.c, when the listing's on the wall.
> > And when I watch the lightning burn unbelievers to a crisp,
> > I know God had six days to work. So he wrote it all in Lisp.
> >
> > [1] https://www.gnu.org/fun/jokes/eternal-flame.en.html
>
> But before you get too carried away, there's this: https://xkcd.com/224/

In addition, here are the relevant versions:

https://xkcd.tw/224
https://explainxkcd.com/wiki/index.php/224:_Lisp

Re: Closures in Emacs and their usage scenarios.

[Arthur Miller]

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" :).

Re: Closures in Emacs and their usage scenarios.

[Emanuel Berg via Users list for the GNU Emacs text editor]

Hongyi Zhao wrote:

>>> And God wrote in Lisp code every creature great and small.
>>> Don't search the disk drive for man.c, when the listing's
>>> on the wall. And when I watch the lightning burn
>>> unbelievers to a crisp, I know God had six days to work.
>>> So he wrote it all in Lisp.
>>>
>>> [1] https://www.gnu.org/fun/jokes/eternal-flame.en.html
>>
>> But before you get too carried away, there's this: https://xkcd.com/224/
>
> In addition, here are the relevant versions

Hm, this is idiomatic English meaning ... ?

If just translated word by word to Swedish, it is not
something I would say to a Japanese engineer. Or any woman!
And not just because the Japanese engineer doesn't know
Swedish ...

> https://xkcd.tw/224
> https://explainxkcd.com/wiki/index.php/224:_Lisp

This comes up all the time it seems. I still don't understand
the pattern and metapattern part.

The word metapattern can mean a lot of things but reading the
Wikipedia article it says "[i]t is a pattern of patterns".

Then it says:

  The Dutch computer scientist Pieter Wisse proposed a method
  called Metapattern for conceptual modeling: a technique for
  meta-information analysis and modeling that emphasizes
  reusability. The method is described in his book
  Metapattern: Context and Time in Information Models [1]

I don't know how that refers to Lisp, or how Lisp refers to
that, and I'm unsure if I ever did "conceptual modeling" or
"meta-information analysis".

Hm, "meta-information analysis", wasn't that what Mr.
Snowden and NSA was/are up to?

But I've read his book - he doesn't mention Lisp ...

@book{i-allmanhetens-tjanst-permanent-record,
  author     = {Edward Snowden},
  isbn       = {978-91-7343-975-6},
  publisher  = {Leopard},
  title      = {I allmänhetens tjänst (Permanent Record)},
  translator = {Stefan Lindgren},
  year       = {2019 (2019)}
}

[1] https://en.wikipedia.org/wiki/Metapattern

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

Re: Closures in Emacs and their usage scenarios.

[Emanuel Berg via Users list for the GNU Emacs text editor]

> I'm unsure if I ever did "conceptual modeling" or
> "meta-information analysis".

  A conceptual model is a representation of a system.
  It consists of concepts used to help people know,
  understand, or simulate a subject the model represents.
  It is also a set of concepts. In contrast, physical models
  are physical objects, such as a toy model that may be
  assembled and made to work like the object it
  represents. [1]

That simple! ... OK

A physical model can also be a photo model I take it ...

And "meta-information" = metadata ?

[1] https://en.wikipedia.org/wiki/Conceptual_modeling

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

Re: Closures in Emacs and their usage scenarios.

[tomas]

[-- Attachment #1: Type: text/plain, Size: 933 bytes --]

On Tue, Sep 28, 2021 at 07:29:56PM +0800, Hongyi Zhao wrote:
> On Tue, Sep 28, 2021 at 6:40 PM <tomas@tuxteam.de> wrote:
> >
> > On Tue, Sep 28, 2021 at 04:54:23PM +0800, Hongyi Zhao wrote:
> >
> > [...]
> >
> > > And God wrote in Lisp code every creature great and small.
> > > Don't search the disk drive for man.c, when the listing's on the wall.
> > > And when I watch the lightning burn unbelievers to a crisp,
> > > I know God had six days to work. So he wrote it all in Lisp.
> > >
> > > [1] https://www.gnu.org/fun/jokes/eternal-flame.en.html
> >
> > But before you get too carried away, there's this: https://xkcd.com/224/
> 
> In addition, here are the relevant versions:
> 
> https://xkcd.tw/224

Oh! I like this one :-)

Although to my shame I've to admit that I don't understand much of
it. I could recognise about three signs in all. Life is sh short...

Thanks for posting :)

Cheers
 - t

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: Closures in Emacs and their usage scenarios.

[Hongyi Zhao]

On Tue, Sep 28, 2021 at 9:57 PM <tomas@tuxteam.de> wrote:
>
> On Tue, Sep 28, 2021 at 07:29:56PM +0800, Hongyi Zhao wrote:
> > On Tue, Sep 28, 2021 at 6:40 PM <tomas@tuxteam.de> wrote:
> > >
> > > On Tue, Sep 28, 2021 at 04:54:23PM +0800, Hongyi Zhao wrote:
> > >
> > > [...]
> > >
> > > > And God wrote in Lisp code every creature great and small.
> > > > Don't search the disk drive for man.c, when the listing's on the wall.
> > > > And when I watch the lightning burn unbelievers to a crisp,
> > > > I know God had six days to work. So he wrote it all in Lisp.
> > > >
> > > > [1] https://www.gnu.org/fun/jokes/eternal-flame.en.html
> > >
> > > But before you get too carried away, there's this: https://xkcd.com/224/
> >
> > In addition, here are the relevant versions:
> >
> > https://xkcd.tw/224
>
> Oh! I like this one :-)
>
> Although to my shame I've to admit that I don't understand much of
> it. I could recognise about three signs in all.

Do you mean you can't read Chinese characters?

> Life is sh short...

Life is so short ...

Why do you have this feeling here?

HZ

Re: Closures in Emacs and their usage scenarios.

[Hongyi Zhao]

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.

[1] https://letoverlambda.com/textmode.cl/guest/chap2.html

HZ

Re: Closures in Emacs and their usage scenarios.

[tomas]

[-- Attachment #1: Type: text/plain, Size: 544 bytes --]

On Tue, Sep 28, 2021 at 10:31:53PM +0800, Hongyi Zhao wrote:
> On Tue, Sep 28, 2021 at 9:57 PM <tomas@tuxteam.de> wrote:

[...]

> > Although to my shame I've to admit that I don't understand much of
> > it. I could recognise about three signs in all.
> 
> Do you mean you can't read Chinese characters?

Only a handful, alas :-(

> > Life is sh short...
> 
> Life is so short ...
> 
> Why do you have this feeling here?

I only managed to learn a few languages, and all of them
are in my near comfort zone.

Cheers
 - t

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: Closures in Emacs and their usage scenarios.

[Emanuel Berg via Users list for the GNU Emacs text editor]

Hongyi Zhao wrote:

>> Life is so short ...
>
> Why do you have this feeling here?

If only it was only here ...

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

Re: Closures in Emacs and their usage scenarios.

[Stefan Monnier via Users list for the GNU Emacs text editor]

> (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))))))

Note that in real life closures that share some of their environment
with another closure are quite rare.

And captured variables that are mutated are also quite rare (and in
languages like Haskell or OCaml they can't exist since variables aren't
mutable ;-).

So I don't find such examples very useful to teach closures.


        Stefan

Re: Closures in Emacs and their usage scenarios.

[Tomas Hlavaty]

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.  The best thing about closures is that they allow
wrapping state mutations under simple interface of funcall.

Re: Closures in Emacs and their usage scenarios.

[Emanuel Berg via Users list for the GNU Emacs text editor]

> Here is one example - note that the byte-compiler will warn
> that "the function ‘align-from-left’ is not known to be
> defined." Well, OK.

I think you can shut the byte-compiler up by using
`declare-function', see the source.

Is this the rare case of a mutable variable BTW?

Interesting if so, since it is the only use case I can think
of, maybe except for several functions sharing the same data
(OK, let's say that data won't change).

;;; -*- lexical-binding: t -*-
;;;
;;; this file:
;;;   https://dataswamp.org/~incal/emacs-init/align-from-left.el

(require 'cl-lib)

(let ((alf-regexp))
  (defun align-from-left (&optional set-regexp)
    (interactive "p")
    (let ((default-regexp "^\\|[[:punct:]]\\|[[:space:]][[:alnum:]]"))
      (unless (stringp set-regexp)
        (cl-case set-regexp
          ( 4 (setq alf-regexp (read-regexp "regexp: ")))
          (16 (setq alf-regexp default-regexp))
          ( t (unless alf-regexp
                (setq alf-regexp default-regexp) )))))
    (let ((beg (point))
          (re  (or (and (stringp set-regexp) set-regexp)
                    alf-regexp) ))
      (when (re-search-backward re (line-beginning-position) t)
        (while (looking-at "[[:space:]]")
          (forward-char 1) )
        (insert (make-string (- beg (point)) ?\s)) ))))

(declare-function align-from-left nil)
(defalias 'alf #'align-from-left)

(provide 'align-from-left)


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

Re: Closures in Emacs and their usage scenarios.

[Stefan Monnier]

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), but in my experience in ELisp
they're the exception rather than the rule and IIUC it's the same in Scheme.

Note also that such mutated+captured variables are more costly (at
least in the most prevalent way to implement closures).  E.g. in ELisp,
a code like

    (let ((x 0))
      (lambda () (setq x (1+ x))))

will be turned into

    (let ((x' (list 0)))
      (lambda () (setcar x' (1+ (car x')))))

[ With more work we could avoid such a rewrite in the above case, but
  it's basically unavoidable in more complex cases like:

    (let ((x 0))
      (list
        (lambda () (setq x (1+ x)))
        (lambda () x)))

  Note that the same kind of rewrite is used in many/most Scheme
  implementations.  ]

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

You may be fond of that feature but closures are very valuable even
without it.


        Stefan

Re: Closures in Emacs and their usage scenarios.

[Tomas Hlavaty]

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.

RE: [External] : Re: Closures in Emacs and their usage scenarios.

[Drew Adams]

> closures and dynamic binding does not go together well.

Why do you say that?  Can you point to a problem,
say, with Common Lisp, which was designed to have
both since its inception?

Re: Closures in Emacs and their usage scenarios.

[Emanuel Berg via Users list for the GNU Emacs text editor]

Tomas Hlavaty wrote:

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

Well, "[s]upport for lexical scoping in Emacs Lisp" came in
Emacs 24.1. I don't know if you can ask Emacs when something
came or when a particular version came, but that mail to
info-gnu-emacs is dated 2012-06-10, so that's not yesterday. [1]
It is 9y 3m 19d ago.

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

It would help to see examples of the most base use cases.
One can always combine it into whatever level of complexity
one desires after that ...

> The toggle-counter-direction is an interesting example.

I don't understand what it is supposed to show?

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

Okay, can you show this? I mean the streams ...

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

Oh, no, not this again ... the counter example (not a pun), is
that an example of a "shared closure" (several defuns closing
it), with a "state" (what I called memory earlier) in the form
of the "captured variable" `times', and that variable is
"mutated" since it's value is altered with the `cl-incf',
`cl-decf' and `setq' setters, while in Haskell and OCaml -
which don't allow that - instead of changing the variable one
would instead have to add a new one, and that wouldn't work
here, since it is all based on operations targeted at
ONE variable?

Is that a correct interpretation of the terminology?

;;; -*- lexical-binding: t -*-
;;;
;;; this file:
;;;   http://user.it.uu.se/~embe8573/emacs-init/times.el
;;;   https://dataswamp.org/~incal/emacs-init/times.el

(require 'cl-lib)

(let ((times))
  (defun times-incf (&optional x)
    (cl-incf times (or x 1)) )

  (defun times-decf (&optional x)
    (cl-decf times (or x 1)) )

  (defun times-reset (&optional x)
    (setq times (or x 0) ))

  (defun times-print ()
    (insert (number-to-string times)) ))

;; (times-reset)     ;    0
;; (times-reset 100) ;  100
;; (times-print)     ; "100"
;; (times-incf)      ;  101
;; (times-incf 10)   ;  111
;; (times-decf 111)  ;    0
;; (times-decf)      ;   -1

So here we see a theoretical use case, which is the OO design.

In practice, there are two use cases what I can see, one is
the state (the persistent variable between calls) and the
other is sharing data between functions.

Maybe you see something more, do tell ...

And, what other use cases are there? Again, keep examples as
simple as possible ...

>> Note also that such mutated+captured variables are more costly (at
>> least in the most prevalent way to implement closures).
>
> [...] In any case, optimizing this is not really a high
> priority issue I think.

Well, if someone wants to do it it doesn't really matter what
the priority is ... it's always like that BTW.

[1] https://lists.gnu.org/archive/html/info-gnu-emacs/2012-06/msg00000.html

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

Re: Closures in Emacs and their usage scenarios.

[Emanuel Berg via Users list for the GNU Emacs text editor]

Stefan Monnier wrote:

> How rare can depend on the language (as mentioned: they are
> completely absent from Haskell/OCaml and friends)

  OCaml 1996 Objective Caml. OOP Caml ML. INRiA, France

seems to be related to

  SML   1990 Standard Meta Language

If so I seem to remember very vaguely (I might be wrong here)
that variables in SML (mosml) wasn't called variables but
"identifiers", maybe because if they can't "mutate" as you put
it one would think there isn't any real variety to their game
anyway ...

https://dataswamp.org/~incal/#bot
https://dataswamp.org/~incal/bot/scripts/hist
https://dataswamp.org/~incal/COMP-HIST

Please add to/correct the COMP-HIST file :)

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

Re: Closures in Emacs and their usage scenarios.

[Hongyi Zhao]

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.

Re: Closures in Emacs and their usage scenarios.

[Emanuel Berg via Users list for the GNU Emacs text editor]

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

RE: [External] : Re: Closures in Emacs and their usage scenarios.

[Tomas Hlavaty]

On Wed 29 Sep 2021 at 22:25, Drew Adams <drew.adams@oracle.com> wrote:
>> closures and dynamic binding does not go together well.
>
> Why do you say that?  Can you point to a problem,
> say, with Common Lisp, which was designed to have
> both since its inception?

Maybe I should have been more precise.  There is no problem with Common
Lisp it this regard.  Common Lisp has lexical binding.  Emacs Lisp did
not have lexical binding until recently.  Dynamic variables are not
closed over so you cannot create a closure if your lisp does not have
lexical binding.  There are still such lisps that do support dynamic
bindings only.  Try to create a closure in such Lisp and see the
workarounds.  The point I was trying to make, that closures might not be
used much in Emacs Lisp so far, because lexical binding is rather new
there, not because there are a few use-cases.

Re: Closures in Emacs and their usage scenarios.

[Tomas Hlavaty]

On Thu 30 Sep 2021 at 08:59, Hongyi Zhao <hongyi.zhao@gmail.com> wrote:
> On Thu, Sep 30, 2021 at 6:11 AM Tomas Hlavaty <tom@logand.com> wrote:
> What's the exact meaning of "the same fringe problem"?

Just search it.  It's trivial to find.  There was a good discussion on
the c2 wiki with great solutions, but that requires javascript these
days, so I will not link to that.

Re: Closures in Emacs and their usage scenarios.

[Hongyi Zhao]

On Thu, Sep 30, 2021 at 7:58 PM Tomas Hlavaty <tom@logand.com> wrote:
>
> On Thu 30 Sep 2021 at 08:59, Hongyi Zhao <hongyi.zhao@gmail.com> wrote:
> > On Thu, Sep 30, 2021 at 6:11 AM Tomas Hlavaty <tom@logand.com> wrote:
> > What's the exact meaning of "the same fringe problem"?
>
> Just search it.  It's trivial to find.  There was a good discussion on
> the c2 wiki with great solutions, but that requires javascript these
> days, so I will not link to that.

https://rosettacode.org/wiki/Same_fringe

HZ

RE: [External] : Re: Closures in Emacs and their usage scenarios.

[Drew Adams]

> >> closures and dynamic binding does not go together well.
> >
> > Why do you say that?  Can you point to a problem,
> > say, with Common Lisp, which was designed to have
> > both since its inception?
> 
> Maybe I should have been more precise.  There is no problem with Common
> Lisp it this regard.  Common Lisp has lexical binding.  Emacs Lisp did
> not have lexical binding until recently.  Dynamic variables are not
> closed over so you cannot create a closure if your lisp does not have
> lexical binding.  There are still such lisps that do support dynamic
> bindings only.  Try to create a closure in such Lisp and see the
> workarounds.  The point I was trying to make, that closures might not
> be used much in Emacs Lisp so far, because lexical binding is rather
> new there, not because there are a few use-cases.

Oh, so you really meant that closures don't fit
well with a language that has _only_ dynamic binding.

That's different.  Thanks for clarifying.

Re: Closures in Emacs and their usage scenarios.

[Emanuel Berg via Users list for the GNU Emacs text editor]

Tomas Hlavaty wrote:

>> What's the exact meaning of "the same fringe problem"?
>
> Just search it. It's trivial to find. There was a good
> discussion on the c2 wiki with great solutions, but that
> requires javascript these days, so I will not link to that.

Christ, lucky you your code speaks another language ...

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

Re: [External] : Re: Closures in Emacs and their usage scenarios.

[Emanuel Berg via Users list for the GNU Emacs text editor]

Tomas Hlavaty wrote:

> The point I was trying to make, that closures might not be
> used much in Emacs Lisp so far, because lexical binding is
> rather new there, not because there are a few use-cases.

Elisp is from 1985, lexical binding was introduced in 2012,
now it is 2021.

(/ (- 2021 2012) (- 2021 1985) 1.0) ; 0.25

So, has it been there 25% of the time?

But that doesn't give an accurate picture even, because there
are many more Elisp hackers in 2021 than in 2012 and there
were more in 2012 than in 1985.

I'm too tired to put that into the calculation, Mr. t of the
official tuxteam of the Federal Republic of Germany maybe can
help me out?

But it's fair to say it has been there enough. If it hasn't
been explored as you say there may be other reasons for
that ...

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

Re: Closures in Emacs and their usage scenarios.

[Arthur Miller]

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.

Re: [External] : Re: Closures in Emacs and their usage scenarios.

[Hongyi Zhao]

On Thu, Sep 30, 2021 at 11:55 PM Emanuel Berg via Users list for the
GNU Emacs text editor <help-gnu-emacs@gnu.org> wrote:
>
> Tomas Hlavaty wrote:
>
> > The point I was trying to make, that closures might not be
> > used much in Emacs Lisp so far, because lexical binding is
> > rather new there, not because there are a few use-cases.
>
> Elisp is from 1985, lexical binding was introduced in 2012,
> now it is 2021.
>
> (/ (- 2021 2012) (- 2021 1985) 1.0) ; 0.25
>
> So, has it been there 25% of the time?
>
> But that doesn't give an accurate picture even, because there
> are many more Elisp hackers in 2021 than in 2012 and there
> were more in 2012 than in 1985.
>
> I'm too tired to put that into the calculation, Mr. t of the
> official tuxteam of the Federal Republic of Germany maybe can
> help me out?

What do you mean by saying "the official tuxteam of the Federal
Republic of Germany"?

HZ

Re: Closures in Emacs and their usage scenarios.

[Stefan Monnier via Users list for the GNU Emacs text editor]

>>>> And captured variables that are mutated are also quite rare
[...]
> In Emacs Lisp, closures mutating captured variables might be rare now
> because lexical scoping arrived recently.
[...]
> 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.

Compared to the existing routine use of closures all over the place,
these remain exceptions hence my characterization of "rare".
This is just as true in Common Lisp and Scheme as in ELisp, even though
they have supported closures for a lot longer.


        Stefan

Lisp books (was: Re: Closures in Emacs and their usage scenarios.)

[Emanuel Berg via Users list for the GNU Emacs text editor]

Arthur Miller wrote:

> 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" :)

To anyone fluent with the Emacs Wiki, please add a book
section with Lisp books.

These two and the ones I've mentioned is a good start and from
GNU there should be a few as well...

@book{land-of-lisp,
  author     = {Conrad Barski},
  isbn       = 1593272812,
  publisher  = {No Starch},
  title      = {Land of Lisp},
  year       = {2010}
}

@book{lispcraft,
  author     = {Robert Wilensky},
  isbn       = 0393954420,
  publisher  = {Norton},
  title      = {LISPcraft},
  year       = {1984}
}

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

Re: Lisp books

[Stefan Monnier via Users list for the GNU Emacs text editor]

> To anyone fluent with the Emacs Wiki, please add a book
> section with Lisp books.

SICP should be there as well, of course,


        Stefan

RE: [External] : Lisp books (was: Re: Closures in Emacs and their usage scenarios.)

[Drew Adams]

[-- Attachment #1: Type: text/plain, Size: 321 bytes --]

> To anyone fluent with the Emacs Wiki, please add a book
> section with Lisp books.

How to use Emacs Wiki:
https://www.emacswiki.org/emacs/SiteMap#h5o-1

How to edit Emacs Wiki:
https://www.emacswiki.org/emacs/HowToEdit

How to create new Emacs Wiki pages:
https://www.emacswiki.org/emacs/CreateNewPages



[-- Attachment #2: winmail.dat --]
[-- Type: application/ms-tnef, Size: 13460 bytes --]

Re: Lisp books

[Emanuel Berg via Users list for the GNU Emacs text editor]

Stefan Monnier via Users list for the GNU Emacs text editor wrote:

>> To anyone fluent with the Emacs Wiki, please add a book
>> section with Lisp books.
>
> SICP should be there as well, of course,

And you own "Evolution of Emacs Lisp" ...

https://www.iro.umontreal.ca/~monnier/hopl-4-emacs-lisp.pdf

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

Re: [External] : Lisp books (was: Re: Closures in Emacs and their usage scenarios.)

[Emanuel Berg via Users list for the GNU Emacs text editor]

Drew Adams wrote:

>> To anyone fluent with the Emacs Wiki, please add a book
>> section with Lisp books.
>
> How to use Emacs Wiki:
> https://www.emacswiki.org/emacs/SiteMap#h5o-1
>
> How to edit Emacs Wiki:
> https://www.emacswiki.org/emacs/HowToEdit
>
> How to create new Emacs Wiki pages:
> https://www.emacswiki.org/emacs/CreateNewPages

Okay, but did you or anyone else do it? Post the URL here if
and when it happens ...

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

Re: Lisp books

[Stefan Monnier via Users list for the GNU Emacs text editor]

Emanuel Berg via Users list for the GNU Emacs text editor [2021-10-05 12:08:53] wrote:
> Stefan Monnier via Users list for the GNU Emacs text editor wrote:
>>> To anyone fluent with the Emacs Wiki, please add a book
>>> section with Lisp books.
>> SICP should be there as well, of course,
> And you own "Evolution of Emacs Lisp" ...
> https://www.iro.umontreal.ca/~monnier/hopl-4-emacs-lisp.pdf

That's not a book, it's just an article.  And that's already mentioned
in EmacsWiki (under ResearchAboutEmacs), and with the proper URL.


        Stefan

Re: Lisp books

[Emanuel Berg via Users list for the GNU Emacs text editor]

Stefan Monnier via Users list for the GNU Emacs text editor wrote:

>>> SICP should be there as well, of course,
>>
>> And you own "Evolution of Emacs Lisp" ...
>> https://www.iro.umontreal.ca/~monnier/hopl-4-emacs-lisp.pdf
>
> That's not a book, it's just an article. And that's already
> mentioned in EmacsWiki (under ResearchAboutEmacs)

Okay, good!

> with the proper URL

Well, it is interesting that you say it because I got it from
Googling "History of Emacs Lisp" - which I thought was the
title ...

Maybe that could be a book project for you BTW?

But not just Emacs Lisp but "History of Lisp"?

It would cover the history of Lisp (the language) of course,
all the dialects, but also how it was implemented and put into
various settings (Lisp machines and so on, with
illustrations/photos), in industry and the university world,
_and_ not the least there would be code extracts so, while not
a manual or standard specification, it would be a book for the
real engineer as well, not just for "tech history buff"?

Well, think about it ;) But I get it you have your own
project(s) that take a lot of time already ...

Maybe there could even be some money in it even tho that
should never be the sole driving force when doing stuff ...

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

RE: [External] : Lisp books (was: Re: Closures in Emacs and their usage scenarios.)

[Drew Adams]

[-- Attachment #1: Type: text/plain, Size: 348 bytes --]

> >> To anyone fluent with the Emacs Wiki, please add a book
> >> section with Lisp books.
> >
> > How to use Emacs Wiki:...
> 
> Okay, but did you or anyone else do it? Post the URL here if
> and when it happens ...

Did you do it?
If so, share the URL here, if you like.

The wiki secretarial pool is on strike
now, for some reason.

[-- Attachment #2: winmail.dat --]
[-- Type: application/ms-tnef, Size: 13580 bytes --]

Re: [External] : Lisp books (was: Re: Closures in Emacs and their usage scenarios.)

[Emanuel Berg via Users list for the GNU Emacs text editor]

Drew Adams wrote:

>>>> To anyone fluent with the Emacs Wiki, please add a book
>>>> section with Lisp books.
>>>
>>> How to use Emacs Wiki:...
>> 
>> Okay, but did you or anyone else do it? Post the URL here
>> if and when it happens ...
>
> Did you do it?
> If so, share the URL here, if you like.
>
> The wiki secretarial pool is on strike now, for some reason.

Please then remove my post and all the book references I have
selflessly compiled.

Because if no one's gonna do it, I don't want ANYONE to use my
work either!

Uhm ...

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

Re: Lisp books

[Stefan Monnier via Users list for the GNU Emacs text editor]

> But not just Emacs Lisp but "History of Lisp"?

Try https://dl.acm.org/doi/10.1145/155360.155373
or the director's cut: https://www.dreamsongs.com/Files/HOPL2-Uncut.pdf


        Stefan

Re: Lisp books

[Emanuel Berg via Users list for the GNU Emacs text editor]

Stefan Monnier via Users list for the GNU Emacs text editor wrote:

>> But not just Emacs Lisp but "History of Lisp"?
>
> Try https://dl.acm.org/doi/10.1145/155360.155373 or the
> director's cut:
> https://www.dreamsongs.com/Files/HOPL2-Uncut.pdf

Wow, that seems to be very close to what I asked for! Awesome!

But ... don't let that get in the way, remember there are not
just one book about WW2!

Or even the American Civil War! LOL

(Some people say there are more books about the
American Civil War than on all other wars - including the Lisp
wars - combined.)

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

Re: Lisp books

[Emanuel Berg via Users list for the GNU Emacs text editor]

I know the title: Lisp Legends!

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

Re: Lisp books

[tomas]

[-- Attachment #1: Type: text/plain, Size: 754 bytes --]

On Tue, Oct 05, 2021 at 09:43:09PM -0400, Stefan Monnier via Users list for the GNU Emacs text editor wrote:
> > But not just Emacs Lisp but "History of Lisp"?
> 
> Try https://dl.acm.org/doi/10.1145/155360.155373

I learnt to despise those: they have become cookie/javascript
black holes [1] as of late.

> or the director's cut: https://www.dreamsongs.com/Files/HOPL2-Uncut.pdf

*That*'s how links in the Internet are, in my wildest dreams!

Cheers

[1] By default, my browser doesn't do any of them. No, I don't
   think they are after me. But I'm fed up by all that slimy
   stuff, kind of the vacuum cleaner salespeople of the XXI.
   Yes, consider me as a kind of a funny Internet Vegan or
   something. I won't mind ;-D

 - t

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: Lisp books

[Emanuel Berg via Users list for the GNU Emacs text editor]

tomas wrote:

>>> But not just Emacs Lisp but "History of Lisp"?
>> 
>> Try https://dl.acm.org/doi/10.1145/155360.155373
>
> I learnt to despise those: they have become
> cookie/javascript black holes [1] as of late.

Indeed, didn't work for me either (or I gave up, maybe).

>> or the director's cut:
>> https://www.dreamsongs.com/Files/HOPL2-Uncut.pdf
>
> *That*'s how links in the Internet are, in my
> wildest dreams!

Indeed (again)

> [1] By default, my browser doesn't do any of them. No,
>    I don't think they are after me. But I'm fed up by all
>    that slimy stuff, kind of the vacuum cleaner salespeople
>    of the XXI. Yes, consider me as a kind of a funny
>    Internet Vegan or something. I won't mind ;-D

Indeed!

You can do this [last] with Emacs-w3m. I remember a discussion
where there was a page and you'd visit and it'd tell you the
footprint you made. What happened with Emacs-w3m an my setting
was ironically that it made such a small footprint, it was
highly unusual :) But I'm not a tin-hat enough to think
anything bad can really happen to anyone because of that.
Maybe in China or Belarus? Even so, why gamble ...

Now tomas you seem to think your sentiments are rare but they
are not.

The only thing to add is a note on JavaScript which, _in
general_, and as you know, isn't "a shabby-construction
web-programming language with a C++ syntax".

"Hello, everyone, this is 2021 calling. Please update your
calendars, it is no longer the 1990s", as it was put.

(setq w3m-add-user-agent nil)

(setq w3m-use-cookies nil)

(setq w3m-use-refresh nil)
(defun w3m-display-progress-message (_))

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

Re: Lisp books

[Stefan Monnier via Users list for the GNU Emacs text editor]

>> > But not just Emacs Lisp but "History of Lisp"?
>> Try https://dl.acm.org/doi/10.1145/155360.155373
> I learnt to despise those: they have become cookie/javascript
> black holes [1] as of late.

They do use javascript a lot more than I'd like, but `M-x eww` renders
it quite acceptably for me.


        Stefan

Re: Lisp books

[tomas]

[-- Attachment #1: Type: text/plain, Size: 775 bytes --]

On Wed, Oct 06, 2021 at 08:37:22AM -0400, Stefan Monnier via Users list for the GNU Emacs text editor wrote:
> >> > But not just Emacs Lisp but "History of Lisp"?
> >> Try https://dl.acm.org/doi/10.1145/155360.155373
> > I learnt to despise those: they have become cookie/javascript
> > black holes [1] as of late.
> 
> They do use javascript a lot more than I'd like, but `M-x eww` renders
> it quite acceptably for me.

What killed them for me is their cookie message:

  "We use cookies to ensure that we give you the best experience
   on our website."

This is corporate Newspeak for: "don't want to be tracked? Go
pound sand". That's OK with me. They don't like me, I don't
like them, We agree on something :)

But that's me, I know.

Cheers
 - t

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[OFFPTOPIC] ACM digital library (was: Lisp books)

[Stefan Monnier via Users list for the GNU Emacs text editor]

>> >> > But not just Emacs Lisp but "History of Lisp"?
>> >> Try https://dl.acm.org/doi/10.1145/155360.155373
>> > I learnt to despise those: they have become cookie/javascript
>> > black holes [1] as of late.
>> They do use javascript a lot more than I'd like, but `M-x eww` renders
>> it quite acceptably for me.
> What killed them for me is their cookie message:
>   "We use cookies to ensure that we give you the best experience
>    on our website."
> This is corporate Newspeak for: "don't want to be tracked? Go
> pound sand". That's OK with me. They don't like me, I don't
> like them, We agree on something :)

But the ACM is not a corporation, it's a professional organization
that's supposed to serve its members, such as myself (hence the `.org`
compared to Springer's `.com`).

They get sucked into corporate newspeak, indeed, and they haven't
converted their library to Open Access (tho it's in the plans and some
of the articles are, such our HOPL-4 paper but apparently not the above
HOPL-2 paper) but I think we should lobby them to get better rather than
shun them (after all, most of the alternatives are worse and beholden to
corporate interests, except for those which don't intend to provide
anything more than archival services, such as LIPIcs or arXiv).


        Stefan

Re: [OFFPTOPIC] ACM digital library (was: Lisp books)

[tomas]

[-- Attachment #1: Type: text/plain, Size: 976 bytes --]

On Wed, Oct 06, 2021 at 04:24:41PM -0400, Stefan Monnier via Users list for the GNU Emacs text editor wrote:

[...]

> But the ACM is not a corporation, it's a professional organization
> that's supposed to serve its members, such as myself (hence the `.org`
> compared to Springer's `.com`).

I didn't imply it was. I think it's just a case of "cultural hegemony".
Or something.

> They get sucked into corporate newspeak, indeed, and they haven't
> converted their library to Open Access (tho it's in the plans and some
> of the articles are, such our HOPL-4 paper but apparently not the above
> HOPL-2 paper) but I think we should lobby them to get better rather than
> shun them (after all, most of the alternatives are worse and beholden to
> corporate interests, except for those which don't intend to provide
> anything more than archival services, such as LIPIcs or arXiv).

I don't shun /them/, just their web site :-)

Actually I do appreciate the ACM.

Cheers
 - t

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [OFFPTOPIC] ACM digital library (was: Lisp books)

[Yuri Khan]

On Thu, 7 Oct 2021 at 03:58, <tomas@tuxteam.de> wrote:

> I didn't imply it was. I think it's just a case of "cultural hegemony".
> Or something.

You mean you’d prefer if their cookie warning looked more like ArtLebedev’s?

    We are using cookies on all our websites including this one
    because without cookies the entire Internet would go to shit.

    [ Fine ]

(Blame the legislators for the necessity to warn about cookies at all.
Cookies as designed are just a way for the web server to correlate
your two sequential requests to each other, including letting you stay
logged in for more than a single request.)

Re: [OFFPTOPIC] ACM digital library (was: Lisp books)

[Emanuel Berg via Users list for the GNU Emacs text editor]

Yuri Khan wrote:

> You mean you’d prefer if their cookie warning looked more
> like ArtLebedev’s?
>
>     We are using cookies on all our websites including this one
>     because without cookies the entire Internet would go to shit.
>
>     [ Fine ]

All the more reason to stop using them ...

But I was actually surprised as well when I first saw it:

  https://dataswamp.org/~incal/figures/yikes.png

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

Re: [OFFPTOPIC] ACM digital library

[Stefan Monnier]

>> I didn't imply it was. I think it's just a case of "cultural hegemony".
>> Or something.
>
> You mean you’d prefer if their cookie warning looked more like ArtLebedev’s?
>
>     We are using cookies on all our websites including this one
>     because without cookies the entire Internet would go to shit.
>
>     [ Fine ]
>
> (Blame the legislators for the necessity to warn about cookies at all.
> Cookies as designed are just a way for the web server to correlate
> your two sequential requests to each other, including letting you stay
> logged in for more than a single request.)

In the current discussion there is no need to correlate two sequential
requests (e.g. noone is logged in).


        Stefan

Re: Closures in Emacs and their usage scenarios.

[Hongyi Zhao]

On Fri, Oct 1, 2021 at 11:37 AM Arthur Miller <arthur.miller@live.com> wrote:
> 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.

I'm learning "Advising Emacs Lisp Functions"[1] now. According to my
current superficial understanding, it seems that both closure and
advice function are intended to provide a clean and concise method to
patch/repair/adapt the existing function/macros with a most consistent
way.

[1] https://www.gnu.org/software/emacs/manual/html_mono/elisp.html#Advising-Functions

HZ

Re: Closures in Emacs and their usage scenarios.

[Emanuel Berg via Users list for the GNU Emacs text editor]

Hongyi Zhao wrote:

> I'm learning "Advising Emacs Lisp Functions" now.
> According to my current superficial understanding, it seems
> that both closure and advice function are intended to
> provide a clean and concise method to patch/repair/adapt the
> existing function/macros with a most consistent way.

That should be one of many use cases for advising functions,
I don't know how one does that with closure tho ...

I've still only seen two use cases for closures, one is the
persistent variable (in C you'd use a static variable, in
Python just a global one) and the other one is the sharing of
one "almost global" variable between two or more functions (in
both C and Python, that would be a real global variable
instead).

And the second use case is a version of the first, or
extension perhaps, since that variable (or set of variables)
would also be persistent. It looks a lot like OOP to me -
I say it in that order because I learned the OOP basics/theory
before I heard of closures, but I expect closures were
actually first, right? - and it is even the very core of OOP
(the coupling/enclosure of data and functions/methods that
operate that data) - so we can say not without reason that
Lisp is the original OOP - with the core stuff implemented in
such as simple way - but without all the other stuff that no
one uses anyway :)

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

Re: Closures in Emacs and their usage scenarios.

[Marcin Borkowski]

On 2021-10-10, at 16:16, Emanuel Berg via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org> wrote:

> Hongyi Zhao wrote:
>
>> I'm learning "Advising Emacs Lisp Functions" now.
>> According to my current superficial understanding, it seems
>> that both closure and advice function are intended to
>> provide a clean and concise method to patch/repair/adapt the
>> existing function/macros with a most consistent way.
>
> That should be one of many use cases for advising functions,
> I don't know how one does that with closure tho ...
>
> I've still only seen two use cases for closures, one is the
> persistent variable (in C you'd use a static variable, in
> Python just a global one) and the other one is the sharing of
> one "almost global" variable between two or more functions (in
> both C and Python, that would be a real global variable
> instead).
>
> And the second use case is a version of the first, or
> extension perhaps, since that variable (or set of variables)
> would also be persistent. It looks a lot like OOP to me -
> I say it in that order because I learned the OOP basics/theory
> before I heard of closures, but I expect closures were
> actually first, right? - and it is even the very core of OOP
> (the coupling/enclosure of data and functions/methods that
> operate that data) - so we can say not without reason that
> Lisp is the original OOP - with the core stuff implemented in
> such as simple way - but without all the other stuff that no
> one uses anyway :)

Yet another use (which of course - technically - is again a variant of
the same thing) is generating a closure whose behavior depends on the
argument of the function that defines it.

<shameless plug>

A simple example from my book:

(defun negate (fun)
  "Return a function returning the logical opposite of FUN."
  (lambda (&rest args)
    (not (apply fun args))))

</shameless plug>

so that (negate #'zerop) behaves like a function testing its argument
for "non-zeroness" (i.e., returning t unless its argument is 0, when it
returns nil).

As a homework, try to use it under dynamic binding and see why it won't
work.  (See also this thread:
https://lists.gnu.org/archive/html/help-gnu-emacs/2021-09/msg00267.html .)

Best,

-- 
Marcin Borkowski
http://mbork.pl

Re: Closures in Emacs and their usage scenarios.

[Emanuel Berg via Users list for the GNU Emacs text editor]

Marcin Borkowski wrote:

> Yet another use (which of course - technically - is again
> a variant of the same thing) is generating a closure whose
> behavior depends on the argument of the function that
> defines it.

Not following?

> (defun negate (fun)
>   "Return a function returning the logical opposite of FUN."
>   (lambda (&rest args)
>     (not (apply fun args))))

Yes, I remember, no, I know you can do a lot with `lambda'
(anonymous function I believe :)), I mean just the

  (let ((...) ...)
    (defun ... )
    ...
    )

syntax Here are the 1 + a use cases I know of, where a -> 1.

;;; -*- lexical-binding: t -*-
;;;
;;; this file:
;;;   http://user.it.uu.se/~embe8573/emacs-init/geh.el
;;;   https://dataswamp.org/~incal/emacs-init/geh.el

(require 'cl-lib)

(let ((dope 1337))
  (defun hope ()
    (message "Hope is %d Dope" (cl-incf dope)) ))
;; (hope)

(let ((forward #'forward-char))
  (defun you-can-not-advance ()
    (apply forward '(1)))
  (defun you-can-not-redo ()
    (setq forward #'backward-char) ))
;; (you-can-not-advance)
;; (you-can-not-redo)
  
-- 
underground experts united
https://dataswamp.org/~incal

Re: Closures in Emacs and their usage scenarios.

[Marcin Borkowski]

On 2021-10-12, at 01:16, Emanuel Berg via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org> wrote:

> Marcin Borkowski wrote:
>
>> Yet another use (which of course - technically - is again
>> a variant of the same thing) is generating a closure whose
>> behavior depends on the argument of the function that
>> defines it.
>
> Not following?

A function defines (and possibly returns) a closure.  The behavior of
the closure depends on the value of an argument to that function.
Different arguments yield different functions.  Just like the example
below.

>> (defun negate (fun)
>>   "Return a function returning the logical opposite of FUN."
>>   (lambda (&rest args)
>>     (not (apply fun args))))
>
> Yes, I remember, no, I know you can do a lot with `lambda'
> (anonymous function I believe :)), I mean just the
>
>   (let ((...) ...)
>     (defun ... )
>     ...
>     )
>
> syntax Here are the 1 + a use cases I know of, where a -> 1.

What's the difference?  Doesn't `defun` contain an implicit `let' with
the arguments?  IOW, function arguments are much like local variables.

Best,

-- 
Marcin Borkowski
http://mbork.pl

Re: Closures in Emacs and their usage scenarios.

[Emanuel Berg via Users list for the GNU Emacs text editor]

Marcin Borkowski wrote:

> What's the difference? Doesn't `defun` contain an implicit
> `let' with the arguments? IOW, function arguments are much
> like local variables.

Yes but here we are concerned with explicit `let's ...

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

Re: [OFFPTOPIC] ACM digital library (was: Lisp books)

[Emanuel Berg via Users list for the GNU Emacs text editor]

Stefan Monnier via Users list for the GNU Emacs text editor wrote:

> But the ACM is not a corporation, it's a professional
> organization that's supposed to serve its members, such as
> myself (hence the `.org` compared to Springer's `.com`).

As I once thought when smoking weed under a bridge in Riga,
"if the information is free it doesn't matter what services
are sold around it". Yeah, that's right - that wasn't weed but
ordinary tobacco and it was actually a police officer who said
that so I HEARD, rather that thought it ...

Nonetheless I agree ...

I remember during my night black bike shop period -
  https://dataswamp.org/~incal/work-photos/stand.jpg -
I remember reading the DIN number on a hand tool (DIN =
Deutsches Institut für Normung = the German industrial
standard which is used here as well) and thought, hey, it
would be cool to read that!

But the standard, i.e. the damn document as a PDF wasn't free
of charge! They wanted money to just mail the document to you!

Actually maybe the DIM pointed to an ISO ... that sounds
likely. Still it's DIM.

There were documents that were free of charge tho.

So were the documents useful?

Not the ones I saw :)

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

Re: Lisp books

[Emanuel Berg via Users list for the GNU Emacs text editor]

Stefan Monnier via Users list for the GNU Emacs text editor wrote:

>> But not just Emacs Lisp but "History of Lisp"?
>
> Try https://dl.acm.org/doi/10.1145/155360.155373
> or the director's cut:
> https://www.dreamsongs.com/Files/HOPL2-Uncut.pdf

I got a smartphone the other day (two actually, thanks to some
good people :)) so I'm gonna create all the wonderful
EmacsWiki pages I've mentioned so far ...

We will be able to answer meaningful questions, well,
meaningful in the context of programming and computing, but
also trivial "fun facts" like for example - ah, just stay
tuned :)

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