How many device drivers have ever been written in Lisp? I'm not necessarily advocating C as the best way to write high performance, non-allocating code either.

Why, all of them, in a Lisp machine.

Probably zero of them, in any non-Lisp machine.

Lisp is a fairly nuts-and-bolts language suitable for device drivers, depending on what you include in it. The

The basic Lisp evaluation model is close to machine language: Lisp values readily map to words (32 bit, 64 bit, whatever) stored in registers, and pushed onto a conventional stack during function calling.

Lisp compilers can optimize away environments: they can tell when some local variables or function parameters are not being captured by a closure and can live on the stack.

Lisp can compile to re-entrant machine code.

Dynamic memory allocation in contexts such as interrupt time is not off the table. In the Linux kernel, ISR's can call kmalloc; they just have to pass the GFP_ATOMIC flag. Similarly, a Lisp interrupt service routine can still cons up cells or other objects, probably in a limited way that can't trigger a full GC, or block for a page fault.

Parts of such as system can be written in a Lisp notation for a non-Lisp language. Such as, for instance, a "Lispified" assembly language. Thus the saving of registers on entry into an interrupt can still be notated in Lisp; it's just not the normal Lisp, but some S-expressions denoting architecture-specific machine instructions (register to memory, and register to register moves and such). When the system is built, an assembler written in Lisp converts that to the executable code.

Nice write up. I'm not sure "Lispified" assembly language really counts as functional programming though. It suggests a layering approach that I suggested originally. Of course, Lisps ubiquitous linked-list and dynamic types are issues for efficient compilation that are not shared by every functional language. The Mirage project is having a lot of success writing a lot of low-level code in OCaml.

Why would you slavishly try to stick to a functional approach when making device drivers in Lisp (or anything else).

Ever heard of Interlisp-D, Lisp Machines?

Yes I have. But my context was modern mainstream hardware. We won't convince anyone on the merits of functional programming by pointing out the existence these old machines. My argument was "have your cake and eat it too", use FP and low-level languages together.

The problem is that like Alan Kay states, the industry has become pop culture, and very few believe what can be achieved, rather take what they can see today.

To prove a point one is forced to create a system just to prove the others wrong, without any ROI.

Completely agree. I should have better worded my post.

The problem: this was long ago on an OS written largely in Lisp.

On a current typical OS (Windows, Android, iOS, macOS, Linux, ...) the chance of ever seeing a Lisp-based device driver in action is near zero.

It isn't because those ideas failed to get mass adoption that we should ignore them.

I don't think anyone is intentionally ignoring them, just accepting the present reality of hardware designed for C. When Intel finally start selling reduceron hardware graph reduction for my Haskell, I'll be the first in line.