Introducing Project Steadfast
4 points by noteflakes
4 points by noteflakes
Please, please come join the Bablr server! https://discord.gg/NfMNyYN6cX
...and tell me what you think of CSTML. It's basically an XML-family language that is specially designed to be storage for parse trees: https://docs.bablr.org/guides/cstml
https://github.com/bablr-lang/language-en-cstml/blob/trunk/lib/grammar.js
Some more maybe-useful links:
What HTML stored as CSTML looks like: https://github.com/bablr-lang/bablr-docs/blob/trunk/src/content/docs/guides/cstml.cstml
Here's what it looks like to use JS quasiquotes the way you're using quote and unquote: https://github.com/bablr-lang/vite_plugin-cstml-to-jsx/blob/df7c61692703f862edab54b3fe4892a5f1fc88cd/lib/index.js#L222-L256
Basically I'm working on something very similar, just in the JS ecosystem.
Oh, here's the evaluator code, or what I've written of it so far: https://github.com/bablr-lang/es0/blob/trunk/lib/grammar.js (runs parse trees produced by https://github.com/bablr-lang/language-en-es3)
I guess I didn't share the tree format: https://gist.github.com/conartist6/8ce77513e70ade4924c23bf31e762023
Also are you looking at immutable trees? When you do parse(text) the parser takes care of validating that the tree represents a semantically valid program, and since strings are mutable in Ruby it's also handling making a copy of the data that won't change mid-evaluation. When using trees as code as opposed to strings, both these functions are still necessary but will have to work a different way. Somehow you need to know that what you're about to evaluate is deeply immutable data and deeply schema-validated.
If you do use immutable data it's nice for the structure to be incremental, meaning that you can recompose the nodes into other trees. For it to be safe to use a node in more than one tree, nodes can't contain data about their siblings. This seems obvious to me, but evidently it is not obvious to most people, because most people writing parsers attach to each node *the absolute index of the source text in the original input", something like [35 - 52]. (See: https://tree-sitter.github.io/tree-sitter/7-playground.html). This does put some information about siblings on the node itself, namely how many text characters are contained in nodes to the left (in this case 35). This becomes invalid whenever any left siblings or cousins change. Instead the smart thing to do is just to store the width of text contained within the node. It's the same information about your node, just without information from other nodes stuffed in there with it.
But really, how are you going to deal with pre-run tree schema validation and during-run data immutability?