Conventional wisdom states that OS kernels must be written in C in order to achieve the necessary levels of performance. This has been the justification for not using more expressive high level languages.
However, for a few years now implementations of Common Lisp such as SBCL have proven to be just as performant as C. What then are the arguments against redoing the kernel in a powerfully expressive language, namely Common Lisp?
I don't think anyone (at least anyone who knows what they are talking about) could argue against the fact that the benefits in transparency and readability would be tremendous, not to mention all the things that can't be done in C that can be done in Lisp, but there may be implementation details that would make this a bad idea.
>>15
or SymtaOS, where everything is a function:
SYMTA> (symta "lib map: F => F")
($(folder (lib data)) $(file (lib test.png)))
NIL
SYMTA> (symta "lib map: F => F name")
(data `test.png`)
NIL
SYMTA>
Name:
Anonymous2013-05-26 12:58
>>18
and it can potentially detect if FASL misses some external files or garbage collect unreferenced ones
>>21
Syntax allows a lot of syntatic sugar
SYMTA> (symta "lib.data.map{to X: list X.name X.type}")
((chest png) (flower png) (potion png))
NIL
SYMTA> (symta "lib.data.map{X => list X.name X.type}")
((chest png) (flower png) (potion png))
NIL
SYMTA> (symta "lib.data.map{| to X || list X.name X.type}")
((chest png) (flower png) (potion png))
NIL
SYMTA>
Name:
Anonymous2013-05-27 3:12
A DSL for memory and drivers? Why not write them in good suitable, already existent language to start with?
A layered approach is a better idea in my opinion. Write from the metal towards an abstract machine specification, which includes things like memory mapping and address spaces, processes, file system and drivers. Some things in this layer could be implemented in lisp if proper hooks are provided.
This then plugs into a lisp implementation which constitutes the upper part of the kernel and the user space.
Instead of forcing lisp to fit a machine, make the machine fit lisp
I've a few new ideas for Lisp OS security, which would eliminate even the possibility of writing a virus:
Unauthorized program should't be able to access filesystem or internet. Every program should be limited in access only to files and directories provided by the user, while internet access is given only to programs installed under apps.interned_allowed directory. There should be a way to reject privileges given to file/directory handles, so accessing them would produce exception. Users shouldn't see outside of their home directory and all file-sharing should be explicit. User password should be too kept under's home directory, so it could be changed without much fuzz with /etc/passwd.
Name:
Anonymous2013-05-27 4:40
>>26
The file system is an artifact of the limitations of early processors that had no memory virtualization capabilities and had an insufficient memory address word size. Programs and data had to be marshalled out of and back into a logically distinct store because 64K can only hold so much information. Modern 32 and 64 bit processors with memory management units can treat storage as large, slow, persistent memory obviating the contortions required in conventional operating systems to keep data from going away when the computer is shut down.
A heirarchical name space is still required for users to keep track of where they put things but virtual memory can hold that tree structure just as well as inodes can and the judicious use of separate memory spaces can side-step a 4 gigabyte limitation for storage on 32-bit machines.
Name:
Anonymous2013-05-27 4:40
>>25
It's kind of hard to appreciate the differences (between Zmacs and Emacs) from reading a description. It's even hard to appreciate it from using Zmacs. Where the light dawns is when you've been using Zmacs for a while and go back to using plain old Emacs.
What, you mean there's no keystroke to bring up a list of every change I've made in every file on the box? What, you mean there's code on the box whose source I can't pop up with a keystroke? What, you mean I have to run some sort of tags program on source files before I can find definitions? What, you mean there's code on the box that isn't cross-referenced? What, you mean there's running code on the box whose source I can't step into? What, you mean I can't insert references to objects on the screen into my code just by clicking the screen objects?
Zmacs is tightly integrated with Genera, and it's Lisp all the way down to the microcode. Emacs is great, don't get me wrong, but it's at a different remove from the system.
>>26
Much better, only programs reviewed by a comitee of governemt officials, bankers, and representatives of the biggest companies that trade in Wall Street should allow binaries to be uploaded on the Internet.
Name:
Anonymous2013-05-27 9:13
>>30
That's a proof of concept for programming a NES machine in Lisp. We need someone to take it to the next step and implement memory allocation and drivers for something. Whoever does this should do it either for the Raspberry PI architecture or x86.
>>32
Still the main problems are dynamic typing and garbage collection, which could be unpredictable, but using manual memory management and limiting precision to fixnums would just invite bugs. I.e. one would want to use full blown Lisp all the way down, just after bootstrap.
Name:
Anonymous2013-05-27 9:39
>>34
Although modern PCs have fast CPUs, so one could instead hard limit GC heap to just 512kb, which could be collected in a microsecond.
Name:
Anonymous2013-05-27 10:35
>>35
And what if I want to store 513kb of data in memory, huh?
Kernel code can use a few conses for the sake of map and reduces functions, but that is all.
Name:
Anonymous2013-05-27 11:19
I have really crazy idea: files on disk should act directly as functions. So lib.database.select{where job is "programmer"} could be used directly, without referencing the database engine, using deserializer from lib.formats.db, and text file with program code should be directly executable, so so that format handler would jit compile it and cache result.
Name:
Anonymous2013-05-27 11:23
>>38
Unix filesystem already implements it in a half-assed way through /dev/ and ioctl. Lisp OS should take it to extreme - no more files, just closures, so that even symlinks will be implement in userspace.