|
Post Scarcity
A prototype for a post scarcity programming environment
|
This is a document that is likely to be revisited, probably frequently.
Move the existing codebase out of the compile space altogether; it is to be treated as a finished rapid prototype, not extended further, and code largely not copied but learned from.
I'm disappointed with Zig. While the language concepts are beautiful, and if it were stable it would be an excellent tool, it isn't stable. I'm still open to build some of the 0.1.X prototype in Zig, but it isn't the main tool.
I haven't yet evaluated Nim. I'm prejudiced against its syntax, but, again, I'm open to using it for some of this prototype.
But for now, I will continue to work in C.
In the 0.0.X prototype, I tried to do too much in the substrate. I tried to write bignums in C, and in this I failed; I would have done much better to get a very small Lisp working well sooner, and build new features in that.
In 0.1.X the substrate will be much less feature rich, but support the creation of novel types of data object in Lisp.
If a significant proportion of the system is written in Lisp, it must be possible to save a working Lisp image to file and recover it.
I still don't know how to write a compiler, and writing a compiler will still be a major challenge. But I am now much closer to knowing how to write a compiler than I was. I think it's important to have a compiler, both for performance and for security. Given that we do not have a separate execute ACL, if a user can execute an interpreted function, they can also read its source.
Generally this is a good thing. For things low down in the stack, it may not be.
Paged space objects will be implemented largely in line with this document.
Tags will continue to be 32 bit objects, which can be considered as unsigned integer values or as four bytes. However, only the first three bytes will be mnemonic. The fourth byte will indicate the size class of the object; where the size class represents the allocation size, not the payload size. The encoding is as in this table:
| Tag | Size of payload | |||
|---|---|---|---|---|
| Bits | Field value | Hex | Number of words | Number of bytes |
| -— | --------— | — | ------------— | ------------— |
| 0000 | 0 | 0 | 1 | 8 |
| 0001 | 1 | 1 | 2 | 16 |
| 0010 | 2 | 2 | 4 | 32 |
| 0011 | 3 | 3 | 8 | 64 |
| 0100 | 4 | 4 | 16 | 128 |
| 0101 | 5 | 5 | 32 | 256 |
| 0110 | 6 | 6 | 64 | 512 |
| 0111 | 7 | 7 | 128 | 1024 |
| 1000 | 8 | 8 | 256 | 2048 |
| 1001 | 9 | 9 | 512 | 4096 |
| 1010 | 10 | A | 1024 | 8192 |
| 1011 | 11 | B | 2048 | 16384 |
| 1100 | 12 | C | 4096 | 32768 |
| 1101 | 13 | D | 8192 | 65536 |
| 1110 | 14 | E | 16384 | 131072 |
| 1111 | 15 | F | 32768 | 262144 |
Consequently, an object of size class F will have an allocation size of 32,768 words, but a payload size of 32,766 words. This obviously means that size classes 0 and 1 will not exist, since they would not have any payload.
Every page will be 1,048,576 bytes.
Namespaces will be implemented; in addition to the root namespace, there will be at least the following namespaces:
Functions written in the substrate language, intended to be replaced for all normal purposes by functions written in Lisp which may call these bootstrap functions. Not ever available to user code.
Functions written in the substrate language which may be available to user-written code.
Functions, written either in Lisp or in the substrate language, which modify system memory in ways that only trusted and privileged users are permitted to do.
Obviously, for this to work, access control lists must be implemented and must work.
This generation is about producing a better single thread Lisp (but hopefully to build it fast); the hypercube topology is deferred.