6 ms·
I would think that people might wish Emacs Lisp would be a more capable application programming language. For example for an editor with such extensive capabili
by lispm 2y ago
I would think that people might wish Emacs Lisp would be a more capable application programming language. For example for an editor with such extensive capabilities, it would be useful that the language would provide preemptive scheduled threads and related constructs.
On my old Lisp Machine, Zmacs ran in a multi-threaded Lisp roughly in the early 80s. Multiple Zmacs windows each had their own thread. Applications had their own thread. GC has its own threads. Even the mouse has its own thread. It still works that way.
But you don't need a Lisp Machine OS with threaded Lisp for that. Many current implementations of Lisp support multi-threading. An example is SBCL, a natively compiled Common Lisp, which supports native threads on its platforms. Thus an editor written on top of SBCL could make use of that. IDEs of LispWorks and Allegro CL are also multi-threaded and they have their own implementations of Emacs, written in Common Lisp.
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?
Multi-threaded Lisp architectures are more complex. Emacs Lisp tried to be simple. But the stuff written in it long ago was outgrowing the provided simplicity. For a capable extension language it was "good enough" for a long time. For an "application development platform" it's not. Lack of multi-threading in Emacs Lisp and the GNU Emacs architecture is an example.
- ducktective 2y ago>On Lisp Machine, Zmacs ran in a multi-threaded Lisp I wonder what the processing architecture of those Lisp machines were like. Did their "cpu"(?) had special circuitry for implementing lists, CAR and CDR? Was this multi-threaded-ness something built-in in hardware?
- lispm 2y ago> Did their "cpu"(?) had special circuitry for implementing lists, CAR and CDR? It was implemented in Microcode on the CPU. > Was this multi-threaded-ness something built-in in hardware? Some. The process scheduler was written in Lisp. See for an early example on the MIT Lisp Machine: https://github.com/mietek/mit-cadr-system-software/blob/master/src/lispm2/proces.150 https://github.com/mietek/mit-cadr-system-software/blob/mast...
- dokyun 2y agoI think you should clarify that the Lisp machines (at least the early ones that you speak of) were not 'multi-threaded' in the sense of multiprocessing--the only multiprocessing they did was running independent Lisp systems on each of their processors, if they had more than one.
- lispm 2y agoFrom the 1981 4th edition Lisp Machine Manual, page 428ff > 25. Processes > The Lisp Machine supports multi-processing; several computations can be executed "concurrently" by placing each in a separate process. A process is like a processor, simulated by software. Each process has its own "program counter", its own stack of function calls and its own special-variable binding environment in which to execute its computation. (This is implemented with stack groups, see chapter 12, page 163.) These computers could send/receive network traffic, handle the GUI, read from disk, while the user would have processes for each application and window. On my mid 1980s Symbolics 3640 I could compile a Lisp application from scratch in a Lisp REPL for half an hour, while I was using Zmacs to edit code. The practical limitations were CPU speed, memory size, disk speed and the Garbage collector. A full GC would halt everything else. Better incremental GCs helped a lot. In GNU Emacs last I tried I could not use two IELM repls executing Lisp code at the same time. One would block the rest of GNU Emacs Lisp code.
- amszmidt 2y agoThere is a bit to much simplification here, and confusing terminology going on here. Lisp Machines did not have "processes" (as in, Unix processes); a Lisp Machine process just a function - with some special properties. The Lisp Machine only had one processor for the Lisp Machine, and it did absolutely support multi-processing and multi-threading. A good explanation can be found in the Lisp Machine manual: https://tumbleweed.nu/r/lm-3/uv/chinual.html#Processes https://tumbleweed.nu/r/lm-3/uv/chinual.html#Stack-Groups Which is also where all current work on the MIT Lisp Machine is being done. :-)
- medo-bear 2y ago
- amszmidt 2y agoThere is nothing special about CAR and CDR on the Lisp Machine, which should be considered a virtual machine for all intents and purposes that was implemented in microcode. Multi processing was implemented mostly in Lisp, but stack group handling (how the system manages "threads") was done in microcode. The hardware for the CADR is very simple, and has no knowledge of Lisp or the Lisp Machine.
- amszmidt 2y ago> 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 agoEven 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 agoZMail 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 agoThese "tricks" still don't make two GNU Emacs Lisp REPLs in the same GNU Emacs execute arbitrary Lisp code concurrently.
- medstrom 2y agoBut 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?
- anthk 2y ago>sbcl SBCL (and it's one of the fastest Common Lisps out there) ran MCCLIM at glacial speeds in my n270 netbook, kinda like a busy Pentium MMX running Windows 98 where you could see Win32 controls redrawing themselves. OTOH, GNU Emacs' multithreading sucks, but at least the UI it's miles ahead on responsiveness.
- lispm 2y ago> but at least the UI it's miles ahead on responsiveness. One Lisp REPL doing stuff and GNU Emacs is completely dead as long as the Lisp REPL runs that Emacs Lisp code. It's not even slow, it just is completely non-responsive.