Crates.io | simple_term_rewriter |
lib.rs | simple_term_rewriter |
version | |
source | src |
created_at | 2025-01-28 23:19:54.302071 |
updated_at | 2025-02-02 22:17:57.45958 |
description | A basic interface to rewrite concrete tree terms according to a set of rules |
homepage | https://github.com/erwanM974/simple_term_rewriter |
repository | https://github.com/erwanM974/simple_term_rewriter |
max_upload_size | |
id | 1534147 |
Cargo.toml error: | TOML parse error at line 18, column 1 | 18 | autolib = false | ^^^^^^^ unknown field `autolib`, expected one of `name`, `version`, `edition`, `authors`, `description`, `readme`, `license`, `repository`, `homepage`, `documentation`, `build`, `resolver`, `links`, `default-run`, `default_dash_run`, `rust-version`, `rust_dash_version`, `rust_version`, `license-file`, `license_dash_file`, `license_file`, `licenseFile`, `license_capital_file`, `forced-target`, `forced_dash_target`, `autobins`, `autotests`, `autoexamples`, `autobenches`, `publish`, `metadata`, `keywords`, `categories`, `exclude`, `include` |
size | 0 |
I initially wrote this code for this project: hibou.
Since then it has evolved a bit and I decided to repackage it on its own as a library.
This does not claim to be a fully fledged Term Rewriting Library. By that I mean that:
c -> F(c)
)In "src/core", the barebones generic interface is provided.
The library user must provide the type of the operator symbols (i.e., the signature of the formal language the user wants to apply rewriting to).
The notions of terms and positions in those terms are implemented by dedicated data types in "src/core".
As for the rewrite rules, they are represented by a Generic Trait with a "try_apply" function that tries to apply it to a specific (sub)term, returning the result as an Option.
The library user must enumerate the rules and provide an implementation for the "try_apply" function.
The user may then use the resulting system to rewrite concrete terms. In "src/process", this process is automatized, with the possibility to parameterize it in various manners (based on graph_process_manager_core and graph_process_manager_loggers).
As a result, we benefit from (among others) the visualization of the rewriting process as a Graphviz graph. Let us remark, that the visualization of each individual term as a tree is implemented in "src/draw_term".
In "str/tests/barebones_only" a small example that makes only use of the crate's barebones interface is given.
Below is an output produced by a graphviz logger connected to the rewriting process.
In the example process below all paths are computed but we can choose to only compute one.
Of course, depending on the way with which you define the rules, the system is not necessarily guaranteed to be terminating/confluent/convergent. To check that, you should use a dedicated tool (it is not handled here).
TODO
TODO