Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
MatchReport: rework internal data structure of matches. #51
Previously, PatternMatch was both an external interface and an internal match-constructing one.
In this rework, the structure built up internally during the match process contains one consistent tree. This is then converted into the PatternMatch structure for backwards compatibility.
But it can also convert into a ParseTree (which duck-types to a TreeNode). the ParseTree corresponds directly to the input file, so I can use this in the GUI to show how microgrammars match. Then I can change the conversion of microgrammars into TreeNode, which will change how path expressions work with them -- it'll have more detail, and still include all the user-defined terms.
Here is a printout of a ParseTree for
while the ValueStructure for that is:
the ValueStructure is also available from the MatchReport; it contains the user-defined terms only. We can deprecate PatternMatch in favor of this. (although I haven't yet changed the update infrastructure to get an updateable ValueStructure)
You can also get a full explanation of the match, which includes failed matches. For instance,
If I alter the string to ``@ChangeControlled @donkey["24", name = "Eeyore")` (open paren is now a square brace) so that it doesn't match, I can see an explanation of the failure. Here, it didn't consume everything we expected, which was because it found [ instead of (
Currently the MatchReport is only available externally through exactMatchReport. Later I'll extend its availability, so that PatternMatch is not the only structure available outside. ValueStructure and ParseTree are preferable.