Regarding the “datagram” essence of Prose Objects, I’ve just now have achieved better clarity on the model. I’ve long wondered whether a Value should be viewed as the fundamental element, or the Map is the fundamental element. It now seems clear that in a sense we need to think both ways. It is very important to maintain a notion of “file with key=values” as the unit of conversation because this is how so much of conventional computing is organized. From config files to credit card receipts, address card and email datagrams, a file as map of k/vs is a very useful format.

But in understanding the paradigm and in building high-performance systems, it is helpful to focus on the key=values. This is my attempt.

The entire system can be viewed as Values – strings of text whose “keys” are names under which they are stored. For instance, in a file system, a Value is a string stored in a file, and the key is the file name. In a database, the key would be the ID of the database record.

The basic mechanism of Prose Objects is to assign _additional_ names to the Values, to give them additional keys used in the recursive expansion and inheritance.

Let’s express this in git-ish terms (with a nod to Ludovic Dubost, who may have anticipated this mapping).

The Value is a file whose name is the hash of the string. This is how git stores files. A Map is a tree (directory/folder) that references those files using meaningful names (the kind of names we now use for keys). These trees are organized into other trees (directories). These higher level (2nd-Nth level) trees correspond to both: 1) the current system of organization of files into folders [G/Z/ol/*] and 2) the links among Prose Objects. The trees can be traversed in two ways: 1) to add a collection of Values to a namespace of a tree (as is done currently by a link to another file) and 2) to obtain a Value’s string ({G/Z/ol/z6#sec}?). This unifies two concepts that seemed to want unification – the folder hierarchy and the system of links.

Note that this somewhat complicates the notion of a file in the current implementation – each k/v becomes a separate file (or is treated as such). This translation can be handled in interface – each line of a file can be saved as a new file and the “file” can be a folder. But there is a problem or needed refinement because while order does not matter for normal k/vs, it does matter for links (“=[] \n =[]” is not the same thing as “=[] \n =[]”). This needs further thought.

This Value orientation simplifies and adds power.  For instance, you can traverse the file-folder tree for a Value or Map in a way that seems natural but wasn’t possible.  The Values also automatically de-duplicate and connect.

For Prose Objects generally –