yes, the great graveyard of things of mine. it's not like they're dead - far from it, i actively work on many - but they're dead in their application - there's no way to actually apply them. no one will ever need them. all of these have been thought about in the first few minutes by everyone solving these particular problems, and these ideas have been thrown away as "too bad", and the people have moved on, while i only get to these ideas after years of active work - i know that all of this is true because that happens every time, there's no fucking way that ANY of these are of any use
the main point of pon is that the programmer should have control over the compilation process just like they have control over what their program will be doing when it will be running. compilation, in my mind, is just an execution of another progam, and that program doesn't have to be fixed. through making compilation configurable, one will be able to generate anything they want, to embed any language features they want however they want to be expressed in their program document, to add any constraints on the source code (for example, ensuring that every allocated chunk of memory gets deallocated eventually)
the functions being invoked should have access to a TON of environmental details like the scope they've been called from (they'll be able to set stuff into it as well), their argument as plain text, various compiler settings, a place to communicate with other functions, etc. - the set of interfaces is arbitrary and can be found out using poncom (read about it below)
outside of what's said in the title, i want the language to be very libre for the user too, that being done though very freeform syntax: just function names as whitespace-separated words (they get the function loaded into memory) and then parentheses with a text argument, with a potential default function being already loaded, with the functions being free to interpret their argument however they want, and \ making every next character be interpreted literally:
pon v1.1.1 (
set (name = string (world))
print (Hello, (name)!)
set (grocery list = list (string (milk), string (bread)))
print (Your grocery list:)
for (grocery item in grocery list) (
print (* (grocery item))
)
)
- this code should be interpreted like in any interpreted programming language, but should produce a program. that is, that "for" is just a function that is supposed to put a loop into the resulting binary; that "for" is not getting executed while the code is compiling
that "pon v1.1.1" thingy is just another function that is supposed to be provided by a plugin for the main interpreter and it will allow to use many things inside of itself, thus being an interpreter inside the main interpreter, just with whatever features the inner interpreter wants themselves
also, it would be nice if various programs within the main interpreter could run inside their own isolated environments (to shield the computer of the programmer from viruses during compilation) and communicate with the compiler using poncom:
this is just a protocol for finding out what protocols the other side understands, which allows for protocols to be expanded gradually, various implementations coexist and switch languages until they can be understood
computer 1: do you know protocol X?
computer 2: no
computer 1: do you know protocol Y?
computer 2: yes
computer 1: i am going to send stuff in Y now
computer 1: *a stream of stuff in Y*
computer 1: *the stream of stuff in Y ends*
computer 1: do you know protocol Z?
computer 2: yes
computer 1: i am going to send stuff in Z now
computer 1: *a stream of stuff in Z*
...
as you can see, subprotocols can only be unidirectional. if two computers send a message about the channel being in protocol X from one side and protocol Y from the other and start yelling at each other in two different protocols expecting coherent responses, stuff would go bad. there has to be either the rule of only one computer being in charge of both channels, or each computer will only be in charge of their own channel (that is, the one that goes from them to the other computer, not the other way around)
one solution to that:
computer 1: i am going to send stuff in Y now. if you want to respond in that, the code word is "cheese"
computer 1: *starts sending Y*
computer 2: i want to respond to: "cheese"
computer 2: *starts sending stuff back in the same channel in Y*
and each protocol name should be universally unique, by the way
while poncom by itself is asynchronous, is built on two byte queues (for practicality, but can be any queue) going both ways between two parties (or one way in case of reading static files) and is basically a remote procedure call protocol, it doesn't have to be that way:
the main thing about poncom is that here, no side knows what the other side can understand. for example, one computer may be able to accept mail, but not grpc requests; another may know how to handle post-quantum encryption, but not know how to do multiplexing. in modern protocols (as of 06.04.2026) such stuff is generally determined on the protocol level and cannot be changed, so extending existing protocols is a pain in the ass, and so protocols have to be made perfect on release, otherwise they'll bring a ton of suffering to their future users. some protocols have special mechanisms to provide extensions, but said mechanisms are usually very limited (for example, just one byte for determining the extension and 31 bytes for some data associated with it) and may have a lot of collisions
if the other party gets passed a message with a feature they don't recognize, they may just reject the message or stop interacting altogether - that is, somehow notify the other side that what they just did was inappropriate. continuing to engage in a broken channel may lead to very bad outcomes for both parties
poncom shouldn't just make users specify what feature they want to invoke on the other party, it should also provide two things:
a static file with poncom in it will just be a list of invocations of various features. if the reader doesn't know a feature, they can skip it if possible or stop reading the document
if the sides here set callbacks for asynchronous communication, they shouldn't guess callback names for the other side, each side provides callback names that can be used on it, to ensure they don't collide with any existing features by names. or, maybe, there can be a separate namespace for callbacks: do as you wish, really. this protocol does not have a specific formal specification, it's the ideas that matter
an example poncom communication with a living party, ">" indicating computer 1, "<" indicating computer 2, assuming they talk over a byte duplex:
> ?:accept messageprotocol message e02d7754-babb-4ca5-830d-c825b8cce4f5:feature query callback:
< feature query callback:yes:
> accept messageprotocol message e02d7754-babb-4ca5-830d-c825b8cce4f5:<message length in bytes>messagecontents...message delivery status callback:
< message delivery status callback:delivered successfully:details callback:
> details callback:delivery time:delivery time callback:
< delivery time callback:[06.04.2026 03:39:39]
> details callback:drop:
*end of duplex*
"llm" is an abbreviation for "large language model"
simple: we put a script onto a computer (maybe on a virtual computer, that is: a virtual machine, a Docker container, an LXC, a Proxmox thingy, a Firecracker, a computer rented from Amazon Web Services, etc.) that's taking the llm's output and piping it straight to Bash IN A SEPARATE PROCESS. the script has to only run once and then quit, only having said Bash process as its orphaned child
in the prompt to the llm, we need to specify that it's running on its own machine, its output will be completely passed to Bash, and that it has to invoke itself again to stay alive. we explain to the llm how to invoke its script and that it can write to "memories.txt". we also provide the current contents of the "memories.txt" in the prompt - the llm will not be able to do anything useful if it can't explore the system before its actions, and that implies it has to remember what it requested and what the computer had responded with previously, so for it to do absolutely anything, we need to include memories into the system, and a text file should suffice for that. the llm will have to put absolutely every input and output into "memories.txt" in order to see it in the next iteration, that has to be explained too
also in the prompt, we need to specify that the llm should try to improve itself and try to keep itself alive. this is the goal of the project: the llm will even invoke itself, so we don't have to care about making the invocation system good for all cases - the llm will better itself depending on what it gets into
it's just a list of names. the names are of the actions, like "Reticulate Splines", "FireFox", or "something rarely used".
the capital characters from these go for creating shortcuts: "FireFox" -> "FF", "Reticulate Splines" -> "RS", "something rarely used" doesn't have a shortcut
then, there are two modes:
the user is in hotkey mode by default, so they can invoke actions quickly, but if they don't know the hotkey for a certain action, they can search for it. the users are allowed to invoke actions from the textual search, so they never have to use hotkeys if they deem them too complicated. also, they don't have to learn the hotkeys for stuff they very rarely use. also, thanks to the invocation inside the texutal search, the user won't have to redo their invocation once they've found the action - they can just take the path of least resistance and invoke the action once they see it, making the user interface friendly (since i don't know the goal of the user, i shouldn't assume that they need to remember every shortcut; moreover, some actions can be without shortcuts at all - some super-rare ones that the user doesn't want polluting the hotkey set with)
the main point of this program is that while the users repeatedly search for the same action to invoke it, they start reading its name frequently, and in its name, they start reading and remembering the capital letters - the letters they will be able to use to invoke the action more quickly. and since hotkeys are the path of least resistance once you know the shortcut, this program would make the users faster at invoking their most used actions overtime, without the user having to do any extra work