4 ms·

> Compare with GNU Emacs, where Emacs Lisp lacks this feature. Wouldn't you want an mail thread not block the rest of Lisp code? Some Lisp action in the REPL no

> Compare with GNU Emacs, where Emacs Lisp lacks this feature. Wouldn't you want an mail thread not block the rest of Lisp code? Some Lisp action in the REPL not to block the rest of Lisp code? Emacs Lisp does have threads; https://www.gnu.org/software/emacs/manual/html_node/elisp/Threads.html https://www.gnu.org/software/emacs/manual/html_node/elisp/Th...

medstrom 2y ago
Even more simply, `while-no-input` has existed since 2007. And start-process since 1985. It has always been possible to make a mail "thread". If the developer didn't use the old tricks, it doesn't seem likely they will use the thread trick either.
- amszmidt 2y ago
  ZMail on the Lisp Machine would stall the ZMail thread when fetching mail. So you wouldn't be able to compose an email if you'd be fetching 10MiB of mbox. But it isn't so much about tricks, sometimes it is nice if software just works reliably, GNU Emacs has a great track record on that.
- lispm 2y ago
  These "tricks" still don't make two GNU Emacs Lisp REPLs in the same GNU Emacs execute arbitrary Lisp code concurrently.
  - medstrom 2y ago
    But why does that matter? Help me understand. To be fair I haven't used an elisp REPL, unless it counts that I use commands. Any command used in Emacs is an eval step in a REPL. But you mean a REPL as in a console-style interaction, right? It seems an impoverished interaction model, only necessary with other languages since they are not also the editor process. Ok I can't have multiple REPLs but neither can I type on multiple keyboards at the same time. So it seems to only matter when you are going to spin up some noticeable chunk of work to be done in the background, while the user interacts with the editor. And that is totally doable with `while-no-input`. In what situation are you running two or more noticeably slow call stacks that need to happen inside the editor process?
    - _19qg 2y ago
      People seem to use Lisp like it is some impoverished programming model. Why would I want to do things concurrently in one Lisp? Because that's how I use a Lisp system all the time. That's my normal way to do things. > But you mean a REPL as in a console-style interaction, right? I mean > 1 REPL as an example how I would use a Lisp concurrently. Yeah, I can switch between REPLs in micro seconds and run > 1 second activities in each of them. > Any command used in Emacs is an eval step in a REPL And you can't run simple Lisp code in two commands concurrently, neither in a REPL nor in a command. > `while-no-input` Type (while-no-input (dotimes (i 1000000) (print i))) in two Emacs Lisp repls and have them running concurrently. I understand that GNU Emacs can run external processes, external instances of GNU Emacs, external other Lisp systems, that it can provide some limited form of cooperative threads, ... I have lived through this stuff 30 years ago and onwards, when many Lisp implementations used cooperative threading (and some had cooperative threads deeply integrated in their Lisp code, other than GNU Emacs in 2024) and over the years switched to native preemptive threading. I also remember when we got Symmetric Multiprocessing in several Lisp systems roughly 15 years ago.
      - medstrom 2y ago
        That'd be better as (defvar foo-i 0) (defun foo () (while-no-input (while (< foo-i 10000) (print (cl-incf foo-i)))) (when (< foo-i 10000) (run-with-idle-timer 1 nil #'foo))) Make a copy of all that, search-replacing "foo" with "bar". Run (progn (foo) (bar)). Both loops will complete eventually. EDIT: OK, you explained what you call the normal way to do things. What kind of code is this that take >1 second in each repl? Out of curosity.
        amszmidt 2y ago
        > EDIT: OK, you explained what you call the normal way to do things. What kind of code is this that take >1 second in each repl? Out of curosity. One easy example -- listing all the files under the GNU Emacs tree to index them -- you might not want to do it many times but even `find` takes a bit of time. Looping over such a list might also take a bit of time.

medstrom 2y ago

Even more simply, `while-no-input` has existed since 2007. And start-process since 1985. It has always been possible to make a mail "thread". If the developer didn't use the old tricks, it doesn't seem likely they will use the thread trick either.

amszmidt 2y ago
ZMail on the Lisp Machine would stall the ZMail thread when fetching mail. So you wouldn't be able to compose an email if you'd be fetching 10MiB of mbox. But it isn't so much about tricks, sometimes it is nice if software just works reliably, GNU Emacs has a great track record on that.
lispm 2y ago
These "tricks" still don't make two GNU Emacs Lisp REPLs in the same GNU Emacs execute arbitrary Lisp code concurrently.
- medstrom 2y ago
  But why does that matter? Help me understand. To be fair I haven't used an elisp REPL, unless it counts that I use commands. Any command used in Emacs is an eval step in a REPL. But you mean a REPL as in a console-style interaction, right? It seems an impoverished interaction model, only necessary with other languages since they are not also the editor process. Ok I can't have multiple REPLs but neither can I type on multiple keyboards at the same time. So it seems to only matter when you are going to spin up some noticeable chunk of work to be done in the background, while the user interacts with the editor. And that is totally doable with `while-no-input`. In what situation are you running two or more noticeably slow call stacks that need to happen inside the editor process?
  - _19qg 2y ago
    People seem to use Lisp like it is some impoverished programming model. Why would I want to do things concurrently in one Lisp? Because that's how I use a Lisp system all the time. That's my normal way to do things. > But you mean a REPL as in a console-style interaction, right? I mean > 1 REPL as an example how I would use a Lisp concurrently. Yeah, I can switch between REPLs in micro seconds and run > 1 second activities in each of them. > Any command used in Emacs is an eval step in a REPL And you can't run simple Lisp code in two commands concurrently, neither in a REPL nor in a command. > `while-no-input` Type (while-no-input (dotimes (i 1000000) (print i))) in two Emacs Lisp repls and have them running concurrently. I understand that GNU Emacs can run external processes, external instances of GNU Emacs, external other Lisp systems, that it can provide some limited form of cooperative threads, ... I have lived through this stuff 30 years ago and onwards, when many Lisp implementations used cooperative threading (and some had cooperative threads deeply integrated in their Lisp code, other than GNU Emacs in 2024) and over the years switched to native preemptive threading. I also remember when we got Symmetric Multiprocessing in several Lisp systems roughly 15 years ago.
    - medstrom 2y ago
      That'd be better as (defvar foo-i 0) (defun foo () (while-no-input (while (< foo-i 10000) (print (cl-incf foo-i)))) (when (< foo-i 10000) (run-with-idle-timer 1 nil #'foo))) Make a copy of all that, search-replacing "foo" with "bar". Run (progn (foo) (bar)). Both loops will complete eventually. EDIT: OK, you explained what you call the normal way to do things. What kind of code is this that take >1 second in each repl? Out of curosity.
      - amszmidt 2y ago
        > EDIT: OK, you explained what you call the normal way to do things. What kind of code is this that take >1 second in each repl? Out of curosity. One easy example -- listing all the files under the GNU Emacs tree to index them -- you might not want to do it many times but even `find` takes a bit of time. Looping over such a list might also take a bit of time.