by @kchanqvq I have had this observation that Unix is an awful programming language implementation for a really long time. The table below shows how various Unix concepts are just sloppy incarnation of general programming language concepts.
| Unix | Programming Language | Common Lisp |
|---|---|---|
| Directory | Module/namespace/environments… | Package |
| File path | Variable/identifier | Symbol |
$PATH | Module imports | USE-PACKAGE |
| Environment variable | Dynamic variable | Special variable |
| Raw bytes (file content) | Structured Data | Structured Data |
| Executable | Functions | Functions/Macros |
| Process | Actor | Process object (actor-like) |
| Build system | Dependency tracking | asdf |
| Init daemon | Reactive programming | cells or lwcells |
I have since been lamenting why we can’t have a good operating system and a good programming language at the same time. I can’t really say Unix is a good operating system, but it at least does the job of reasonable state maintenance without constant restarts, something most source-file centric “modern” programming languages are complete lacking and all hope of using them as operating systems is lost. We had it in the past – Smalltalk, Lisp Machines, but I still have to use “modern” software to survive. I had started to design my dream operating environment, building on what we had in the last century and what is learned from researches in this century, a structural editor, on a residential Lisp environment, based on F-exprs, reactive programming and partial evaluation… I have been designing for years. I open Emacs and try to code this dozen-year project up from time to time. I type ten lines, then quit. I’m not insane enough to fix the world this way.
But then one day, an idea struck. What if I can make Unix part of a good language environment, even fully disguised as regular citizens of the language? Unix is a language with sloppy corners, after all, but the conceptual gap is small once the right mapping is found, and the sloppy behaviors are concealable. This is the pragmatic rather than idealistic solution. We might obtain a Lispy environment in which existing Unix software just works™, not unlike the Emacs experience, which has ~360k lines of C code as of 2023, runs on Unix, deals with mostly unstructured text buffer not unlike Unix files, yet is still enjoyable enough to use.
So here is this project. The rightmost column in the table lists the better incarnation of programming language concepts found in Common Lisp, into which the corresponding Unix incarnation should be wrapped. Currently, the mapping of directory, file path, $PATH , executable and processes are mostly complete.
Although at the current stage the project may look like a Lispy shell, I do not intend to create yet another™ shell™. There is no shell DSL. All examples are regular Common Lisp! I intend to make the Unix system accessible and used in regular Common Lisp programs and interactions, in a Lispy way if possible.
Maybe a full distro one day, we can dream.
In some early version of Unix in Lisp, we starts the listener in Unix FS package directly, but we soon discover unfixable pitfalls to it. First, Lisp variables and functions entered in the listener become internal to the Unix FS package (directory-local), which is an unintuitive default behavior. Moreover, files in the current directory shadow system commands or Lisp functions, which easily leads to security blunders. I later considered creating a dedicated pacakge for each listener and let them use the Unix FS package of the current directory, but then it become inconvenient to share data between listeners and it’s a pain to maintain package system states when we need to frequently change the current directory package. Moreover, we can’t treat variable and function access to the current directory differently. Eventually I arrive at the current design which treats the current package and the current directory separately.