Document resyntax/grimoire/syntax-path#787
Conversation
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
There was a problem hiding this comment.
Resyntax analyzed 10 files in this pull request and found no issues.
|
coverage: 93.834% (+0.06%) from 93.772% — grimoire-stxpath into master |
The empty syntax path is now called the root syntax path, matching filesystem terminology, and nonempty paths are now called child paths, since every path other than the root refers to a child of some enclosing form. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
There was a problem hiding this comment.
Resyntax analyzed 10 files in this pull request and found no issues.
The previous wording implied flattening was specific to improper lists. In fact all pair-based shapes are canonicalized the same way regardless of how their pairs and syntax objects nest, as covered by the "improper lists - all produce same paths" tests. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
"Flatten" evokes Racket's `flatten` function, which erases all tree structure including nested proper lists. Syntax paths only normalize improper lists into proper ones; nested forms remain distinct children. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
There was a problem hiding this comment.
Resyntax analyzed 10 files in this pull request and found no issues.
There was a problem hiding this comment.
Resyntax analyzed 10 files in this pull request and found no issues.
There was a problem hiding this comment.
Resyntax analyzed 10 files in this pull request and found no issues.
- Fix the broken syntax property tech reference and a typo
- Fix the hash example: #hash keys are implicitly quoted, so ('b . 3)
made the key the list (quote b) rather than the symbol b
- Give the discussion its own linkable subsection and point it and the
comment preservation section in the rules docs at each other
- Document that source-read-syntax and source-expand attach the
'original-syntax-path property, and index that property key with
indexed-racket so it shows up in docs search
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
There was a problem hiding this comment.
Resyntax analyzed 10 files in this pull request and found no issues.
Most of the prose here looks good but there are some sneaky details I decided to call out.
The `@racket[]` form performs some syntax object normalization of its own, so these four syntax objects weren't all rendering as distinct text in the final document. Using `@tt{}` instead of `@racket[]` fixes this (because `@tt` doesn't try to actually parse its input text in any way).
There was a problem hiding this comment.
Resyntax analyzed 10 files in this pull request and found no issues.
There was a problem hiding this comment.
Resyntax analyzed 10 files in this pull request and found no issues.
The path is now validated with syntax-contains-path? before the empty-splice early return, so removing zero children at a nonexistent path raises a contract error instead of silently returning the syntax unchanged. This makes the grimoire's documented claim true. syntax-apply-delta now skips the removal step for pure insertions, since their start paths may point one past the end of the enclosing form, which is a valid insertion point but not a removable child. Also restores a closing brace that went missing from the in-syntax-paths documentation entry and broke the docs build. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
There was a problem hiding this comment.
Resyntax analyzed 10 files in this pull request and found no issues.
There was a problem hiding this comment.
Resyntax analyzed 10 files in this pull request and found no issues.
2 participants
Documents the
syntax-path?API in the grimoire, continuing from #785. Syntax paths are one of the foundational pieces of Resyntax that are used as part of its internal data model of how code moves around, so they're pretty important.