refactor: extract abstract Expression interface #30

2026-01-16T23:35:25Z

mvhutz commented

2026-01-16 23:35:25 +00:00

Description

The codebase currently couples the engine and plugins directly to lambda.Expression.
This PR introduces an abstract expr.Expression interface to enable future support for multiple evaluation modes.

Add pkg/expr/expr.go with an Expression interface requiring a String() method.
Update lambda.Expression to embed expr.Expression.
Add String() method to Abstraction, Application, and Variable types.
Update plugins to use String() instead of lambda.Stringify().

Decisions

The expr.Expression interface is minimal (only String()) to avoid over-constraining future expression types.
The engine still stores *lambda.Expression directly rather than expr.Expression, because Go's interface semantics require pointer indirection for in-place mutation during reduction.
Future evaluation modes will implement their own concrete types satisfying expr.Expression.

Benefits

Establishes a foundation for supporting multiple evaluation modes (SKI combinators, typed lambda calculus, etc.).
Plugins now use the abstract String() method, making them more decoupled from the lambda-specific implementation.
Prepares the codebase for a Reducer interface abstraction in a future PR.

Checklist

Code follows conventional commit format.
Branch follows naming convention (<type>/<description>).
Tests pass (if applicable).
Documentation updated (if applicable).

## Description The codebase currently couples the engine and plugins directly to `lambda.Expression`. This PR introduces an abstract `expr.Expression` interface to enable future support for multiple evaluation modes. - Add `pkg/expr/expr.go` with an `Expression` interface requiring a `String()` method. - Update `lambda.Expression` to embed `expr.Expression`. - Add `String()` method to `Abstraction`, `Application`, and `Variable` types. - Update plugins to use `String()` instead of `lambda.Stringify()`. ### Decisions - The `expr.Expression` interface is minimal (only `String()`) to avoid over-constraining future expression types. - The engine still stores `*lambda.Expression` directly rather than `expr.Expression`, because Go's interface semantics require pointer indirection for in-place mutation during reduction. - Future evaluation modes will implement their own concrete types satisfying `expr.Expression`. ## Benefits - Establishes a foundation for supporting multiple evaluation modes (SKI combinators, typed lambda calculus, etc.). - Plugins now use the abstract `String()` method, making them more decoupled from the lambda-specific implementation. - Prepares the codebase for a Reducer interface abstraction in a future PR. ## Checklist - [x] Code follows conventional commit format. - [x] Branch follows naming convention (`<type>/<description>`). - [x] Tests pass (if applicable). - [ ] Documentation updated (if applicable).

mvhutz added 1 commit 2026-01-16 23:35:25 +00:00

refactor: extract abstract Expression interface eba2182151

Introduce pkg/expr.Expression as a base interface for all evaluatable
expression types, enabling future support for multiple evaluation modes
(SKI combinators, typed lambda calculus, etc.).

- Add pkg/expr/expr.go with Expression interface requiring String() method.
- Update lambda.Expression to embed expr.Expression.
- Add String() method to Abstraction, Application, and Variable types.
- Update plugins to use String() instead of lambda.Stringify().

mvhutz merged commit e0114c736d into main

2026-01-16 23:37:32 +00:00

mvhutz deleted branch refactor/expression-interface

2026-01-16 23:37:32 +00:00

mvhutz referenced this issue from a commit

2026-01-16 23:37:32 +00:00

refactor: extract abstract Expression interface (#30)

mvhutz referenced this issue from a commit

2026-01-16 23:40:20 +00:00

refactor: extract Reducer interface and update engine to use abstractions

mvhutz referenced this pull request

2026-01-16 23:40:31 +00:00