Why not port Linux kernel to Common Lisp?

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.

>>10

(readtable-case *readtable*)
=> :UPCASE
(setf (readtable-case *readtable*) :preserve)
=> :PRESERVE
'a
=> 'a
'A
=> 'A

>>27
The file system is an artifact of the limitations of early processors
Yes, but we're stuck with it because it's what most are used to. The hierarchial file system is simple and robust. It's pretty tedious to serialize and deserialize in some environments, but in shell scripts that treat files almost as variables it's very easy and suitable to use. Also, it's pretty easy to find a way to organize stuff into a hierarchy, as you say in the following.

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.
Even assuming that all files on the machine would fit in a single 32-bit address space, I wonder where do you put the boundary between program data and user data/content? How do I share an image between two programs? Is it so that instead of using files (with the implication that the data is stored on a disk) I have to juggle address spaces (that contain the image in some format) that different programs can map into or out of memory? Or is there no way to separate a program's data (runtime data, code, etc.) and content? Secondly, how would you ensure consistency?

If we're still talking about lisp OS, then I think I see your point. In that case the data would always be in native lisp data structures that every program on the machine understood and which could be passed from program to program as easily as text streams are piped on unix. The operating system would somehow automagically map or copy data structures and serialize them at times of need in the same way processes are currently swapped out.

I have a suggestion (that isn't new), however, for a lisp OS that doesn't go this far, but still throws out the file system. Some operating systems have used relational databases instead of, or in conjunction with a file system to some success. But instead of a full blown relational database, what about using tuple spaces for durable storage and IPC? In processes current-input-port and current-output-port (or equivalents) would be bound to a tuple space from where it could read and write tuples (i.e. lists). Writing a tuple could be done with just plain old write, but as with tuple spaces in general there would be different read procedures for reading or taking a tuple, or getting any or all the tuples that match a certain wild card.

There could be private tuple spaces for programs to store things like settings and other configuration, and shared ones for what would generally be stored on the file system. Tuple spaces were invented to tackle concurrency and parallellism and all the operations on them would naturally be atomic. Finally, there could be distributed tuple spaces for a network of machines where any program with access to the tuple space could read or contribute with data.

Maybe there could be pipes as well.

>>41
That is useless, because all default symbols are |FUCKING-UPPERCASE|.

here is how prototype works http://410chan.org/dev/src/136969236946.png

>>44
hello ilya
kike name. shalom, hymie!

>>42
tl;dr

>>45
He uses a Macbook with Intel. He's such a hypocrite.

>>44
Apple is a company of kikes. So is Intel, which has some of their production plants in Tel Avevil Jerusalem, Haifa, Petach Tikva, Qiryat Gat and Yakum.

Good job supporting the kikes, Nikiketa Sadvosky the closet kike.

>>34
Manual memory management is how the world does their OS. Doing it in Lisp should be easy, am I right?

>>49
It's impossible to manually manage memory in Lisp. It's the reason GC was invented.

>>50
What if you design a language that is pretty much C using Lisp-style infix notation and static type-checking? This language would only be intended for limited applications like the kernel, drivers, high performance apps or bootstrapping a higher Lisp. It wouldn't a full featured and general Lisp language with REPL, homoiconic data, implicit typing and GC.

>>50
That depends on whether your definition of Lisp includes GC, and stuff like closures that would need GC to be useful.

You could still make a language with first class functions, s-expressions and macros, dynamic typing, etc.  Symbolics used low-level Lisp-like languages (or DSLs, whatever) to write device drivers and bootstrap lisp machines.

>MOAR LIEK E/G/IN D/G/IKSTRA XDDDDDDDDDDDD
>/PROG/N

>>45
http://en.wikipedia.org/wiki/Julie_%28given_name%29 isn't a kike name. Moreover, Romans destroyed filthy Jewish empire and killed Jesus the kike.

>>51
You will be severely limited in design
1. no map/reduce
2. no upward funarg
3. integer overflow, because of no bignums
4. insecure design, because of direct memory access
5. no revocable capabilities, because of direct memory access and no GC with upward funargs

>>55
6. slow/complicated syscalls and message passing, because of virtual memory context switches.

>>42
How do I share an image between two programs?
If "image" is a lib/image.png, then calling lib.image would use system or overridden codec to load it as an immutable WxH array, so you can share it among different applications, without crap like load_png("lib/image") or filenames

>>57
And absence of direct filesystem access would enhance overall security, just forbidding unmanaged memory access.

>>58
just LIKE forbidding unmanaged memory access.
self fix

>>55
Isn't that the nature of using a language that requires fine programmer control and machine knowledge? Now thinking about it, I don't really see the point of a C with infix syntax in order to simulate a Lisp-like language, it's probably better to use C instead.

>>56
I sincerely doubt slow syscalls would be an issue when your Lisp language uses a garbage collector that you can't control.

>>60
Isn't that the nature of using a language that requires fine programmer control and machine knowledge?
Nope. Even assembly language provides macro, which trade abstraction for efficiency.

I.e. a funcall in C/C++ is less efficient than a plain goto, yet we use functions anyway.

>I sincerely doubt slow syscalls would be an issue when your Lisp language uses a garbage collector that you can't control.
C/C++ too uses generational garbage collection. It is called "stack", but stores only the first generation.