Graph based droppability

[dabbler0]

Restructures a lot of old code having to do with parenthesis wrapping and droppabilty. Things that were changed:

• Removes the old precedence, socketLevel, and classes fields, replacing them with parseContext, nodeContext, and shape.
  • parseContext must always be a string that can be passed to the parser indicating what AST node to start the parse at when reparsing this node.
  • nodeContext must be an instance of NodeContext, and has information indicating how to un-paren-wrap this node.
  • shape is one of the old socketLevel constants and represents whether to put a nubby in on the block.
• Removes the old XML-based serialization and replaces it with a new JSON-based serialization which is easier to modify.
• Changes the socket reparse behavior to add back the feature where saying a * [b + c] in that socket will add parentheses around (b + c). (TODO add test for this)
• Changes reparse behavior to reparse less things less often to improve performance.

[ttsuchiya]

I think all the similarly-worded "contexts" here (context (== node.parent), node.parseContext, and node.nodeContext.type) can get confusing. Can we omit the input argument's context and use the info from the node itself? (Also applicable to other places using argument context).

[dabbler0]

Maybe we should rename context -> parent? One of the things having the argument gives us it that parens can be called to "prepare" a node for dropping into a new spot before it actually gets dropped there (so node.parent != context).

[ttsuchiya]

Perhaps parseContext can be named as parseContextType to reflect that it's a string type not a NodeContext object?

[ttsuchiya]

I'm adding a few more high-level questions that I wanted to ask in the meeting:

• Is the use of Dijkstra (or DFS) essential for estimating the droppability in real-time?? For performance, maybe we could flatten the tree with all possible children (as array) for each rule, if the paths are not so complex. Also it seems not using the path cost to make use of the Dijkstra (UCS) algorithm.
• How can we go about generating the grammar trees for Python, JS, etc.?

[dabbler0]

Hmm, you're right. What do you think good names would be for parseContext and nodeContext? parseType and innerType, maybe or parseType andunwrappedInfo?parseContextdescribes the outermost parse context used for the block and is used during reparsing, whilenodeContext` describes how to completely unwrap the block of all its parentheses.

I do not know if Dijkstra is essential; the graphs usually do not have a lot of edges so I think performance is not a huge problem (the library I found that finds shortest paths just happens to use it).

It uses the path cost when it figures out how to wrap in parentheses; it seeks to wrap using the fewest number of parenthesis rules possible. For instance, when a + b is dropped into a statement context where it needs to become a + b;, it could theoretically also wrap (a + b);, but the extra () are unnecessary, so we want the least cost path. Not sure whether to pre-flatten -- @davidbau any thoughts?

Right now CoffeeScript and JS still use custom droppability rules, implementing the drop(node...context) function themselves. If we wanted to transition to the new graph-based droppability, we would probably have to write the graph by hand (and possibly add more specific type labeling in the parsers). Depending on how complex we discover the languages to be, this might be easy or difficult.

[ttsuchiya]

How about "outmostClass" (for "parseContext") and "classComponents" (for "nodeContext")? I tried to avoid the words "context" and "type" that are already used in other places (e.g., "node.type", "context.type") with different implications from "nodeContext", "nodeContext.type", etc.

[ttsuchiya]

Sorry, I overlooked that you are using the shortestPath() with costs involved. That probably justifies the use of tree and searching.

[ttsuchiya]

@dabbler0 If you have "example-c.coffee," do you mind checking it in to whichever the up-to-date branch? Thanks!