4 ms·

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

• pjmlp 10y ago
  Ever heard of Interlisp-D, Lisp Machines?
  • lispm 10y ago
    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.
    • pjmlp 10y ago
      It isn't because those ideas failed to get mass adoption that we should ignore them.
      • willtim 10y ago
        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.
  • willtim 10y ago
    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.
    • pjmlp 10y ago
      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.
      • willtim 10y ago
        Completely agree. I should have better worded my post.
• kazinator 10y ago
  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.
  • willtim 10y ago
    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.
    • kazinator 10y ago
      Why would you slavishly try to stick to a functional approach when making device drivers in Lisp (or anything else).