Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Motivated by jackfirth/resyntax#432, as well as inspired by racket-review's use of syntax classes. Define syntax classes closely following the require grammar. Use them to drive the matching and simplification, producing attribute values that are `sortable` structs, from which we reconstruct the syntax. Because the macro-debugger-lib drop analysis works in terms of <module phase> tuples, the root-module-path syntax class is the locus -- it may produce #f instead of a `sortable` to indicate elision. This can percolate up through other specs, since they all build directly or transitively on root-module-path. Simplify gratuitous specs either reducing to the simpler equivalent spec or eliding entirely. e.g. (only-in m) => m or (combine-in) => #f. No longer "explode" multi-in forms when denormalizing and attempt to recover them when normalizing. Instead: Preserve multi-in forms, modifying only for drops. In simple cases like (multi-in a b (c d)), we can modify the multi-in form itself. In the general case -- any Cartesian product -- we must wrap in a subtract-in spec. Change require tidying to work on full file syntax; requires are tidied in all modules. The racket-{trim base}-requires add/drop required modules only in the file's root module, because the macro-debugger lib's analysis only works for that module. As a result of this change, the front end no longer needs to gather and supply a list of require forms. Instead it always just supplies a file path. The back end commands return a list of textual changes -- inserts, deletes, and replaces -- for the front end to make to the buffer. This seems like a cleaner and more appropriate division of labor. Improve some doc strings in substance, and prefer active to passive voice.
- Loading branch information