Background: When a new cst or model is injected, a controller is created for it. The controller has a "binding map template" which is simply a binding map with the same number of variables as the cst or model. The controller's binding map template is set up by HLPBindingMap::init_from_hlp which scans the code of the cst or model looking for variables. Consider this cst (simplified):
It has variables v0 through v4 so the binding map template should have these five variables.
More background: A cst or mdl has a "packed" and "unpacked" version. The packed version has all the code in one array similar to the example shown above. There can be external references such as cst_same_pos, but the relevant code is all together. This is used for evaluating guards, etc. The unpacked version is much smaller and has external references to each of the components, such as the two facts in the example above. This is used, for example, to match with an input fact during forward or backward chaining.
Currently, HLPBindingMap::init_from_hlp scans the unpacked version. This means that it uses init_from_pattern to recurse into every reference, scanning for variables. Normally, this works OK but in this case it recurses into cst_same_pos which has variables v0 through v5 . (This happens because the constant sphere is used instead of a variable v5.) Therefore, the controller's binding map template is set up incorrectly.
This pull request updates HLPBindingMap::init_from_hlp to take the parameter packed_hlp and use the packed version to scan for variables. In this case, it does not need to recurse into referenced objects so we can remove the unused recursive method init_from_pattern. Since the packed version has exactly the needed variables, the controller's binding map template is correct.
Background: When a new cst or model is injected, a controller is created for it. The controller has a "binding map template" which is simply a binding map with the same number of variables as the cst or model. The controller's binding map template is set up by
HLPBindingMap::init_from_hlpwhich scans the code of the cst or model looking for variables. Consider this cst (simplified):It has variables
v0throughv4so the binding map template should have these five variables.More background: A cst or mdl has a "packed" and "unpacked" version. The packed version has all the code in one array similar to the example shown above. There can be external references such as
cst_same_pos, but the relevant code is all together. This is used for evaluating guards, etc. The unpacked version is much smaller and has external references to each of the components, such as the two facts in the example above. This is used, for example, to match with an input fact during forward or backward chaining.Currently,
HLPBindingMap::init_from_hlpscans the unpacked version. This means that it usesinit_from_patternto recurse into every reference, scanning for variables. Normally, this works OK but in this case it recurses intocst_same_poswhich has variablesv0throughv5. (This happens because the constantsphereis used instead of a variablev5.) Therefore, the controller's binding map template is set up incorrectly.This pull request updates
HLPBindingMap::init_from_hlpto take the parameterpacked_hlpand use the packed version to scan for variables. In this case, it does not need to recurse into referenced objects so we can remove the unused recursive methodinit_from_pattern. Since the packed version has exactly the needed variables, the controller's binding map template is correct.