Settings

Theme

Show HN: A small reasoning engine that learns rewrite rules from two examples

4 points by heavymemory 10 days ago · 3 comments · 1 min read

Reader

I have been experimenting with structural reasoning and built a small engine that learns rewrite rules from only two examples. You provide a pair of before and after expressions and it works out the transformation and applies it to new inputs. There is no LLM, no regex and no hard coded logic.

The demo includes:

TEACH (learn a rule from two examples)

COMPOSE (several learned rules used together) TRANSFER (a rule learned in algebra also works in logic and sets)

SIMPLIFY (multi step deterministic rewriting with a visible trace)

CODEMOD (teaching a codemod from two examples)

It runs on a CPU and produces a reasoning trace for every step. I would be interested to know what people think or where it breaks.

Demo: https://re.heavyweather.io

heavymemoryOP 10 days ago

If anyone saw odd behaviour just now in the demo, that was my fault. One of the codemod rules was leaking into the shared rule registry instead of being scoped to the current user. I have isolated that and it should be fixed.

The core engine was not affected. The issue was simply that a user taught rule was visible to other demo modes, which made it fire that rule everywhere.

If anyone notices anything else strange, let me know. It should behave normally now.

RossBencina 10 days ago

Interesting. Are there more examples somewhere? I'm curious about cases where multiple examples are required. The associativity "example" corresponds directly to the rewrite rule definition, so it doesn't really illuminate the distinction between specifying a rewrite rule and inferring a rule from multiple examples.

  • heavymemoryOP 10 days ago

    Right, associativity is the simplest case because the structure is visible directly in one example.

    The system needs multiple examples when there is more than one varying part and a single example is ambiguous. A simple example is wrapping a function call. With:

        doThing(x) → log(doThing(x))
        process(y) → log(process(y))
    
    the system learns that: the function name varies the argument varies he outer log(…) is constant

    From that it infers the general rule and applies it to new inputs. A single example would not be enough to disambiguate that pattern.

Keyboard Shortcuts

j
Next item
k
Previous item
o / Enter
Open selected item
?
Show this help
Esc
Close modal / clear selection