You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, the search can only fill the first child of a node.
The children of a rulenode are a vector, and once a child is expanded, a new RuleNode is pushed to this vector.
Therefore, we can only expand a hole once all 'sibling' holes on the left are filled.
To make this general expand function work, we need to change how this works.
I think the best way to solve this is by introducing a special 'hole' RuleNode, e.g. a rulenode with ind=0 that we can use as a placeholder or by instantiating the children as a vector filled with 'nothing'.
I agree it is a good idea to explicitly introduce a 'hole' node. RuleNodewith ind=0 is a good convention for that.
Do you expect that the ability to fill in holes in different orders will impact some of the methods significantly? We anyways cannot evaluate an expression until all of its 'hole' children are filled.
I don't think there will be a big impact on existing methods. Of course, the expand function has to be modified, and we do need to check existing functions for e.g. length(node.children). I know I have used this a couple of times to check whether all holes are filled, but I think this is mainly in the SpecificationExtraction repository.
It might also be a good idea to add a check to the rulenode2expr function for when you are trying to convert a partial tree to an expression. Right now you would probably get some index out of range exception.
Create an extendible expand function
Update: Explicit Hole objects can now be added to the RuleNode tree, eliminating the problem described in the conversation below.
The text was updated successfully, but these errors were encountered: