Chunk rules can be used to manipulate and update other rules. The built-in meaning of terms that start with '@' gets in the way. To work around that you can map a chunk rule in the rule model to a set of chunks in another module, where the '@' terms are mapped to terms you can readily manipulate. The reverse process maps set of chunks in another module to a rule in the rule model, reversing the mapping.
This needs to be documented in the chunks and rules specification in terms of @compile, @uncompile, @map and @source
Here is what I wrote some years back:
The @compile property can be used with a chunk identifier to compile a set of chunks into a rule. This is needed as the use of @ terms in goals and rules interferes with retrieving or storing chunks involving these terms. The compilation process maps to these terms when copying chunks to the rule module. The default mapping simply inserts an @ character before the name, e.g. mapping do to @do. If the application needs to use the reserved terms for other purposes, you can reference your own map to the standard terms by using @map to reference a chunk with the map, e.g. if you wanted to use m instead of module, and diff instead of distinct:
@map {
m module
diff distinct
}
Note that for compile, @source identifies the module for the chunk referenced by @compile. In principle, there could be an @uncompile property which takes a chunk identifier for a rule in the rule module, and puts the mapped rule chunks into the module referenced by @source, and at the same time, placing the corresponding rule chunk into that module's buffer. This would provide an opportunity for inspection over procedural knowledge. Further work is needed to check whether this capability is really needed. See below for a brief discussion of the potential for declarative reasoning over rules as part of the process of learning how to address new tasks.
Issue: perhaps we should use @module instead of @source given that the rule module is implicit, on the assumption that there is only one rule module.
A rule is a chunk with the properties @condition and @action. The property values are the list of chunks for the conditions and actions respectively. There is a suite of @do actions that can be used to manipulate and update chunks. A rule could have an action with an @compile property whose value is the chunk ID for a rule to be compiled to the rule module. The same action could have an @map property to reference one or more @map chunks as explained above.
Chunk rules can be used to manipulate and update other rules. The built-in meaning of terms that start with '@' gets in the way. To work around that you can map a chunk rule in the rule model to a set of chunks in another module, where the '@' terms are mapped to terms you can readily manipulate. The reverse process maps set of chunks in another module to a rule in the rule model, reversing the mapping.
This needs to be documented in the chunks and rules specification in terms of @compile, @uncompile, @map and @source
Here is what I wrote some years back:
The
@compileproperty can be used with a chunk identifier to compile a set of chunks into a rule. This is needed as the use of@terms in goals and rules interferes with retrieving or storing chunks involving these terms. The compilation process maps to these terms when copying chunks to the rule module. The default mapping simply inserts an @ character before the name, e.g. mapping do to@do. If the application needs to use the reserved terms for other purposes, you can reference your own map to the standard terms by using@mapto reference a chunk with the map, e.g. if you wanted to use m instead of module, and diff instead of distinct:Note that for compile,
@sourceidentifies the module for the chunk referenced by@compile. In principle, there could be an@uncompileproperty which takes a chunk identifier for a rule in the rule module, and puts the mapped rule chunks into the module referenced by@source, and at the same time, placing the corresponding rule chunk into that module's buffer. This would provide an opportunity for inspection over procedural knowledge. Further work is needed to check whether this capability is really needed. See below for a brief discussion of the potential for declarative reasoning over rules as part of the process of learning how to address new tasks.Issue: perhaps we should use
@moduleinstead of@sourcegiven that the rule module is implicit, on the assumption that there is only one rule module.A rule is a chunk with the properties
@conditionand@action. The property values are the list of chunks for the conditions and actions respectively. There is a suite of@doactions that can be used to manipulate and update chunks. A rule could have an action with an@compileproperty whose value is the chunk ID for a rule to be compiled to the rule module. The same action could have an@mapproperty to reference one or more@mapchunks as explained above.