Not Dead
Loper should not be considered truly dead until I myself am dead and buried. Currently available computing systems are brain-damaged in such wholesale, unmitigable ways that I am driven back to the project again and again, despite the oceanic size and nearly certain futility of the task. Working full time and being back in school (in a field unrelated to computing) have slowed my Loper work to a crawl. Yet I try to use my scarce free moments to think - and most of the work which must be done here will consist of thinking, rather than coding. This is because my ultimate aim is to drain the complexity swamp in which programmers have drowned. At any rate, the project should be considered a failure if the alpha version exceeds, say, 20,000 lines of code.
Important conceptual progress has been made by others. In particular, there now exists a working experimental operating system, "LoseTheOS", which, among other virtues,
- was written from scratch
- tailored to the AMD-64 architecture
- does away with most aspects of the compile/pray/debug cycle
- does away with the programs-as-ascii-globs dogma
- is in the public domain.
I fully intend to build on this progress and learn whatever lessons there are to be learned from this masterpiece.
Mencius Moldbug of Unqualified Reservations once remarked in his criticism of Haskell and other products of modern academia that most programming "on the ground" consists of juggling database queries. If, as I suspect, this claim is even partly true, this fact alone proves that most programming is entirely unnecessary and that the livelihood of most programmers is quite like that of the glassmaker in the Parable of the Broken Window.
The bootloader is complete, as previously announced. Where to now?
- Initialization of 64-bit memory management data structures
- Basic display driver for QEMU, Bochs, and VMWare virtual SVGA cards
- PIO disk access driver
- And, of course, the Loper Lisp JIT compiler. "First, steal a chicken..."
Expect more in the near future.
> The bootloader is complete, as previously announced. Where to now?
It seems that the next step is to have that bootloader actually load something...but what? The next stage of the boot process needs to be the lisp kernel. This lisp kernel would be a software simulation of the Lisp Machine hardware. However, it does not need to be a functional duplicate of that hardware.
I suggest that you read up on LispKit and SECD machines:
http://en.wikipedia.org/wiki/Lispkit_Lisp
http://en.wikipedia.org/wiki/SECD_machine
Your lisp kernel would be part of a more complicated architecture:
Level 4 - User Environment + compiler
Level 3 - Operating System (memory & hardware mgmt)
Level 2 - SECD Machine
Level 1 - bootloader
Level 0 - AMD64 Hardware
There are online copies of the SECD VM here:
http://skelet.ludost.net/sec/
http://www.ocs.net/~jfurman/lispkit/
http://jatha.sourceforge.net/
Your kernel should be probably highly optimized and done in assembly so it is fast. You'll need to design the memory architecture too as the ones above seem pretty lame to me. You could borrow ideas from earlier lisp machines (3600, Scheme 79 etc).
You may even want to get fancy and implement tail recursion at the VM level:
http://www.cs.utexas.edu/users/boyer/ftp/nqthm/trsecd/trsecd.html
Cheerio...
Stanislav, you say "juggling database queries". In Lisp whit what is replase databases? How lisp program stored their data???