refactor: Extract stack effects from hardcoded match statement to data structure #208

New issue

Closed

opened 2026-01-09 04:42:45 +00:00 by navicore · 1 comment

navicore commented

2026-01-09 04:42:45 +00:00

(Migrated from github.com)

Problem

crates/repl/src/app.rs contains a 214-line function get_word_effect() (lines 1022-1236) with 100+ match arms, each defining stack effects in nearly identical patterns:

"dup" => Some(StackEffect::new(
    "dup",
    Stack::with_rest("a").push(StackValue::var("x")),
    Stack::with_rest("a").push(StackValue::var("x")).push(StackValue::var("x")),
)),
"drop" => Some(StackEffect::new(
    "drop", 
    Stack::with_rest("a").push(StackValue::var("x")),
    Stack::with_rest("a"),
)),
// ... 100+ more identical patterns

Impact

Maintenance nightmare: changing stack effect representation requires 100+ edits
Error-prone: easy to introduce inconsistencies
No validation: typos in word names silently fail
Bloated code: 214 lines for what should be declarative data

Proposed Solution

Option 1: Declarative macro

define_stack_effects! {
    dup:    (a x -- a x x),
    drop:   (a x -- a),
    swap:   (a x y -- a y x),
    over:   (a x y -- a x y x),
    // ...
}

Option 2: External data file (TOML/JSON)

[effects]
dup = { before = "a x", after = "a x x" }
drop = { before = "a x", after = "a" }

Option 3: Build-time generation

Generate from compiler's builtin definitions to ensure single source of truth.

Files Affected

crates/repl/src/app.rs (lines 1022-1236)
Potentially new crates/repl/src/effects.rs or data file

Acceptance Criteria

Stack effects defined declaratively (< 50 lines of definitions)
Single source of truth for word effects
Compile-time validation of effect syntax
All visualization features continue to work

Labels

refactor, technical-debt, critical

## Problem `crates/repl/src/app.rs` contains a 214-line function `get_word_effect()` (lines 1022-1236) with 100+ match arms, each defining stack effects in nearly identical patterns: ```rust "dup" => Some(StackEffect::new( "dup", Stack::with_rest("a").push(StackValue::var("x")), Stack::with_rest("a").push(StackValue::var("x")).push(StackValue::var("x")), )), "drop" => Some(StackEffect::new( "drop", Stack::with_rest("a").push(StackValue::var("x")), Stack::with_rest("a"), )), // ... 100+ more identical patterns ``` ## Impact - Maintenance nightmare: changing stack effect representation requires 100+ edits - Error-prone: easy to introduce inconsistencies - No validation: typos in word names silently fail - Bloated code: 214 lines for what should be declarative data ## Proposed Solution ### Option 1: Declarative macro ```rust define_stack_effects! { dup: (a x -- a x x), drop: (a x -- a), swap: (a x y -- a y x), over: (a x y -- a x y x), // ... } ``` ### Option 2: External data file (TOML/JSON) ```toml [effects] dup = { before = "a x", after = "a x x" } drop = { before = "a x", after = "a" } ``` ### Option 3: Build-time generation Generate from compiler's builtin definitions to ensure single source of truth. ## Files Affected - `crates/repl/src/app.rs` (lines 1022-1236) - Potentially new `crates/repl/src/effects.rs` or data file ## Acceptance Criteria - [ ] Stack effects defined declaratively (< 50 lines of definitions) - [ ] Single source of truth for word effects - [ ] Compile-time validation of effect syntax - [ ] All visualization features continue to work ## Labels refactor, technical-debt, critical

navicore commented

2026-01-09 05:06:01 +00:00

(Migrated from github.com)

https://github.com/navicore/patch-seq/pull/216