Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

compiling chunk rules #49

Open
draggett opened this issue Jun 25, 2023 · 0 comments
Open

compiling chunk rules #49

draggett opened this issue Jun 25, 2023 · 0 comments

Comments

@draggett
Copy link
Member

draggett commented Jun 25, 2023

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant