streamline deeply nested CST snapshots#726
Conversation
|
Xanewok
left a comment
There was a problem hiding this comment.
I love it and I have mixed feelings at the same time 😅
Flattened nodes is a great idea and I can see immediate benefit, but once we put more glyphs like the arrow, parentheses, the faux colon, I feel like I have to spent some cognitive budget to decipher it and since it's not uniform with the rest of the regular tree this makes it not obvious for me, yet. Maybe I'm just used to the old format and I'll have to get used to this one, as well?
Torn on putting everything in the parentheses. On one hand it's nice and feels a bit like the (name: type) syntax, but on the other, it feels lispy and like you'd want to nest it but we're stuck with YAML structure (confusing for me at first); the previous one I liked, because only the name was in parentheses and it felt like a good mix, because it's a) optional b) more of a hint, as the structure and the node type is the most important here.
I'm a fan of not omitting whitespace here, since it makes it more uniform and will help some catch some regressions (like the one I introduced for the error recovery, the other day).
I'll let @AntonyBlakey also take a look at this, maybe we can brainstorm a way to make it a bit easier to read.
In any case, great job!
|
@Xanewok thanks for taking a look!
What do you mean by "regular tree"? you mean ASCII codes? I'm happy to use any other glyphs, as long as it is still valid YAML. In any case, I think we can give it a shot, as we can always change it later.
I think once we combine multiple ones on the same line, the fact it is optional is actually confusing, and makes it less clear how different nodes are separated. I suggest we still surround the entire node title (regardless of which metadata it has) with some delimiter. One other alternative is full-width square brackets (below). WDYT? Tree:
-［BreakStatement］: # 0..16 "break invalid ;\n"
-［break_keyword꞉ BreakKeyword］: "break" # 0..5
-［LeadingTrivia］--►［Whitespace］: " " # 5..6 |
I accidentally a word... I meant "regular tree (shape)". Sorry about that! Also, It seems I didn't complete the review by accident; it's a shame that these are only persisted locally... let me try to recreate a comment that I had. |
| - (close_brace) CloseBrace: "}" # 23..24 | ||
| - (Block): # 0..24 "{ unchecked { x = 1; } }" | ||
| - (open_brace꞉ OpenBrace): "{" # 0..1 | ||
| - (statements꞉ Statements) ► (item꞉ Statement) ► (variant꞉ UncheckedBlock): # 1..22 " unchecked { x = 1; }" |
There was a problem hiding this comment.
The flattened path immediately makes sense to me for some terminal path
- (LeadingTrivia) ► (Whitespace): " " # 5..6
but when used in a non-terminal path/a node that has children it's confusing for me, for whatever reason. Maybe it's because it combines quite a bit of glyphs/sigils but also contains rendered children content that may be mistook visually for YAML string value? i.e. # 1..22 " unchecked { x = 1; }" Maybe using different characters like 《content》to disambiguate would help?
I also tried to experiment with piggy-backing on the file structure shorthand forms (used in GitHub interface, VS Code): some/node but the name metadata makes this significantly harder to read.
I don't have more alternatives and I know this is subjective...
Alternatively, maybe we could at first only enable the flattened/shorthand path for terminal paths/nodes and see if it's good enough for now?
This would keep the tree layout consistent, i.e. disallow following confusing structure:
- parent
- child > grandchild:
- great_grandchild: "value"
- child:
- grandchild: "value"
Or maybe doing this not only for terminals as per above but also for always-single-child-nodes (enums) but not for lists/other with 1 child would strike a better balance here?
For example, this might be too big of a shortcut that IMO hurts rather than improves readability:
- (items꞉ TupleValues) ► (item꞉ TupleValue) ► (expression꞉ Expression) ► (variant꞉ EqualityExpression): # 1..11 "foo == bar"
There was a problem hiding this comment.
Maybe using different characters like 《content》to disambiguate would help?
I like those alternative delimiters. But then I did spend years writing APL, so ... :)
I like the regularity of always enclosing, even when there is no label. I love the arrow chars. I'm not keen on the colons that look-like-but-actually-are-some-weird-unicode colons. I think the square brackets are better. But these are all aesthetic opinions. |
f534372 to
25119e2
Compare
Context: #698 (comment)
꞉unicode character instead of colon:to separate node name and kind, in order not to break YAML parsing/formatting.