Open masak opened 5 years ago
Rather than jquery, I think of graspjs
@vendethiel GraspJS looks nice, and we should definitely do something like that in #14. But I'm wondering if we can do something better for selection/manipulation than dropping all the way down to text...
Specifically, I'd want something where we can talk not just about something's (textual) name, but its definition site. Like the reference system in IntelliJ's PSI.
If you're an optimizer step (or something that wanted to transform expressions like #284), or a refactoring tool like #14, or even a test runner, you have a relationship to the Qtree being inspected/manipulated that's a bit different from macros; all the former keep the Qtree at arm's length, whereas macros are inside the document that's being manipulated.
I figure something like jQuery's straightforward manipulation of DOM elements is something we can borrow. I'm thinking particularly of the "select, manipulate" pattern that happens in jQuery. Also, both implicit iteration and method chaining is something that might be helpful. (Though method chaining will end up looking different if we go with #490.)
Concretely, I want to be able to say something like
jQuery is pretty string-based, but it feels like we should lean on names and lexical scoping instead as much as possible. (Which is not a straightforward choice to make; sometimes a brief selector string works wonders.)
As I was thinking about this, I realized that list Qnodes play a special role in the flexibility around this. Statement lists, parameter lists, argument lists, trait lists — all of these are places where we can easily add and remove certain nodes.
It should be possible make a list of the jQuery manipulation methods, and figure out how they apply to manipulating Qtrees.
One thing that's a bit different between DOM/jQuery and Qtrees is that DOM element nodes have attributes whose values are strings, whereas in Q the attributes can be other Qnodes, or any number of non-Q value types besides strings.