previously I linked to https://sr.ht/~plan/plunder/, which used to be the public git repository of the main Plunder codebase. it seems that the page is now private.
I thought it could be helpful to outline some of the main features of Plunder, which in my opinion was/is a very inventive and ingenious attempt to realize Urbit’s vision and address some of the key deficiencies of Urbit, which seemingly doom it to fall short of its goal.
<< TODO: refine this >>
- PLAN
- simple core calculus / representation
- “data jets”
- a way to “project” between simple but inefficient PLAN representations and “hardware accelerated” efficient, but more complex representations inside the runtime
- “jets”: similar to Urbit’s concept, it is analogous to “data jets” but for functions.
- “jetting” a PLAN-defined function allows the runtime to use more efficient code to operate on a PLAN value.
- a “jet” usually operates on a value which is “data jetted”. for example, an array-length function might be used on an array, and under the hood, Haskell’s Data.Vector can be used.
- code is data
- Plunder exhibits “true homoiconicity”, arguably moreso than Lisp, because functions (called Laws in PLAN) are normal values and can be modified using other functions. many Lisps & Schemes will output
#<procedure:...>, or some such, when attempting to print a function. in PLAN, this is a normal value.
- Plunder exhibits “true homoiconicity”, arguably moreso than Lisp, because functions (called Laws in PLAN) are normal values and can be modified using other functions. many Lisps & Schemes will output
- “immortal” programs
- because programs are just data, it is possible to create a function which will hold its state internally, receive inputs, and return outputs.
- in Haskell, this would be approximately
newtype Immortal = Immortal (Input -> (Output, Immortal)).- state would accumulate in the “closure” of the function - potentially huge amounts of state, as a decent PLAN runtime would support memory mapping of Pins.
- event log + snapshots
- a PLAN runtime is based on an event log of system calls. these are all logged, and periodically a full snapshot is written. if the runtime crashes, resumption is as simple as loading the last snapshot, then replaying all logged events since said snapshot.
- imagining an “immortal” program from above - this mechanism allows it to run potentially forever, surviving runtime crashes, power outages, or moves between underlying machines.
- (this of course relies on the PLAN representation itself not changing)
- “hardware” devices
- TODO
- “machines”
- TODO
Pallas / OPFN
some work publicly lives on via https://github.com/operating-function/pallas.