M.V. Hutz
9c7fb8ceba
## Description The codebase previously used "interpreter" terminology and standalone functions for expression operations. This PR modernizes the architecture by renaming to "runtime" and converting operations to receiver methods. - Rename `pkg/interpreter` to `pkg/runtime`. - Move `ReduceOnce` to new `pkg/normalorder` package for reduction strategy isolation. - Convert standalone functions (`Substitute`, `Rename`, `GetFree`, `IsFree`) to receiver methods on concrete expression types. - Change `Set` from pointer receivers to value receivers for simpler usage. - Update all references from "interpreter" to "runtime" terminology throughout the codebase. ### Decisions - Operations like `Substitute`, `Rename`, `GetFree`, and `IsFree` are now methods on the `Expression` interface, implemented by each concrete type (`Variable`, `Abstraction`, `Application`). - The `normalorder` package isolates the normal-order reduction strategy, allowing future reduction strategies to be added in separate packages. - `Set` uses value receivers since Go maps are reference types and don't require pointer semantics. ## Benefits - Cleaner API: `expr.Substitute(target, replacement)` instead of `Substitute(expr, target, replacement)`. - Better separation of concerns: reduction strategies are isolated from expression types. - Consistent terminology: "runtime" better reflects the execution model. - Simpler `Set` usage without needing to manage pointers. ## Checklist - [x] Code follows conventional commit format. - [x] Branch follows naming convention (`<type>/<description>`). Always use underscores. - [x] Tests pass (if applicable). - [x] Documentation updated (if applicable). Reviewed-on: #39 Co-authored-by: M.V. Hutz <git@maximhutz.me> Co-committed-by: M.V. Hutz <git@maximhutz.me>
45 lines
843 B
Markdown
45 lines
843 B
Markdown
---
|
|
name: "Feature Request"
|
|
about: "Suggest a new feature or enhancement for the lambda runtime."
|
|
title: "feat: "
|
|
ref: "main"
|
|
assignees: []
|
|
labels:
|
|
- enhancement
|
|
---
|
|
|
|
## Context
|
|
|
|
<!--
|
|
Describe the problem or limitation you're encountering.
|
|
Explain why this feature would be valuable.
|
|
-->
|
|
|
|
## Proposed Solution
|
|
|
|
<!--
|
|
Describe your proposed solution or enhancement.
|
|
Be specific about what you want to see implemented.
|
|
-->
|
|
|
|
## Alternatives Considered
|
|
|
|
<!--
|
|
List any alternative solutions or approaches you've considered.
|
|
If none exist, omit this section.
|
|
-->
|
|
|
|
## Acceptance Criteria
|
|
|
|
<!--
|
|
List clear, testable criteria that define when this feature is complete.
|
|
Use bullet points starting with •
|
|
-->
|
|
|
|
## Additional Context
|
|
|
|
<!--
|
|
Add any other context, screenshots, or examples about the feature request.
|
|
If none exist, omit this section.
|
|
-->
|