It would help interested visitors of your repository to provide more background about the application domains you are aiming at. "make programming as effective as possible" is a nice high-level goal, but for which kind of programs do you want to achieve this? Readers have to guess from the keywords that follow (database, service, interface - it's pretty clear that you are not thinking about embedded systems, for example).

Ah, good point! I'm still aiming (pretentious and impossible as it sounds) for universality. I wasn't thinking of embedded systems in particular, where you'd perhaps have minimal interfaces.

I'll make a clarification that I want to make it as universal as possible (knowing full well it might be a failure exactly because of this).

Thank you for checking it out!

Also, thank you @Márton Gunyhó for letting me know about xarray.dev! I wish I knew about this library sooner

The future optimization for using less memory reminds me of memoryless textures and sparse textures in GPU coding land. If you don’t need intermediate steps, you can just reuse the memory.

Something you might consider is having the user select what to keep in memory. Provide a simple and unobtrusive UI (e.g. a small button), and some equally unobtrusive UI for figuring out the size of the dataset (e.g. hovering over that button).

Background: as a power user, I much prefer manual control over some superficially smart solution that one day I will have to reverse-engineer and fight to get my work done.

Interesting! Your FIFO reminds me of two somewhat similar (but differently focused) projects I have seen before:

• Tree notation
• The Most Elegant Configuration Language

Both very exciting projects! I love this kind of stuff. Pretty sure I've seen Tree notation during the discovery phase of my research! And the CCL article is a gem, had real fun reading it, the author is much better than me at explaining things

I feel that CCL ended up a bit poisoned by concrete syntax. FIFO can have whatever concrete syntax as long as it follows the higher-order syntax.

I think also that CCL missed the advantage of treating "start of line" as a first-order type/key for encoding multiline values. It makes the whole system even more pure

This is how FIFO is parsed into memory, it's definitely a graph, but I also suspect it's a variation of hypergraphs too, since edges can relate multiple nodes, and even have edges themselves

Now I am a bit lost. What I see is a tree, both visually and in the parsed data. Where are the edges that relate multiple nodes? Where are edges that have edges themselves?

The edges are reified. Nodes prefixed by a dot (meta nodes) are edges/relations between data nodes. The example given was not meant to be a sample demonstrating the qualities I mentioned. Indeed it mostly behaves as a tree due to the text source layout. But when using a live environment, such as a GUI interface, the text representation is not needed, and so it facilitates more advanced compositions. In any case, this is more in theoretical than practical utility, since it's designed for documents and those are naturally tree-like

I haven't gone as far as implementing references and a parsing supporting it, so this is just a mock to demonstrate the layout. I've done it by hand so might contain some errors. I think you can even use the file system to create hypergraphs by interpreting directories as hyperedges and using symbolic links to instantiate nodes (files) across many directories. Basically any tree model can be elevated to a hypergraph with semantic interventions. What's missing from this in-memory repr are multivalued backreferences, which would allow for multiway pathfinding starting at any node

the row schema is [parent_id, relation_id, key, value, meta_relation, data_relation]

There are indeed multiple ways to represent a file system as a (hyper)graph. The question is what you gain from moving to more sophisticated graph representations. A plain file system without links has a well-established representation as a tree. You can choose to represent directories are hyper-edges between files, but unless you add links (which let you add any file to any hyper-edge), you don't gain much from that. Inversely, if your use case profits from hypergraphs, the question is if implementing this hypergraph as a tree plus links is the best concrete representation.