refactor: Extract builtin completions from hardcoded array #214

New issue

Closed

opened 2026-01-09 04:43:23 +00:00 by navicore · 1 comment

navicore commented

2026-01-09 04:43:23 +00:00

(Migrated from github.com)

Problem

crates/repl/src/app.rs (lines 1327-1535) contains a 200+ element hardcoded array of builtin word names for completions:

fn builtin_completions() -> Vec<String> {
    vec![
        "dup".to_string(),
        "drop".to_string(),
        "swap".to_string(),
        "over".to_string(),
        "rot".to_string(),
        // ... 200+ more entries
        "weave.close".to_string(),
    ]
}

Impact

Duplication: This list must be synchronized with:
- Compiler builtins
- Stack effects definitions (see related issue)
- Documentation
Maintenance burden: Adding a new builtin requires updating 3+ locations
Error-prone: Easy to forget to add completions for new words
Stale documentation: Completion descriptions can drift from reality

This is closely related to the stack effects extraction issue - both should ideally share a single source of truth for builtin words.

Proposed Solution

Option 1: Generate from compiler

The compiler already knows all builtins. Export this list and consume it in the REPL:

// crates/compiler/src/builtins.rs
pub const BUILTINS: &[BuiltinDef] = &[
    BuiltinDef { name: "dup", effect: "(a x -- a x x)", category: Category::Stack },
    BuiltinDef { name: "drop", effect: "(a x -- a)", category: Category::Stack },
    // ...
];

// crates/repl/src/completion.rs
fn builtin_completions() -> Vec<String> {
    compiler::builtins::BUILTINS.iter()
        .map(|b| b.name.to_string())
        .collect()
}

Option 2: External data file

# builtins.toml
[[builtins]]
name = "dup"
effect = "(a x -- a x x)"
category = "stack"
description = "Duplicate top of stack"

Build-time codegen creates both compiler definitions and REPL completions.

Option 3: Query LSP for completions

If the LSP server already provides completions, remove the hardcoded fallback entirely and rely on LSP.

Files Affected

crates/repl/src/app.rs (lines 1327-1535)
Potentially crates/compiler/src/builtins.rs (new)
Potentially build script or data file

Acceptance Criteria

Single source of truth for builtin word list
Adding new builtin requires change in exactly one place
REPL completions automatically include all compiler builtins
Remove 200+ lines of hardcoded strings

Labels

refactor, technical-debt, medium-priority

## Problem `crates/repl/src/app.rs` (lines 1327-1535) contains a 200+ element hardcoded array of builtin word names for completions: ```rust fn builtin_completions() -> Vec<String> { vec![ "dup".to_string(), "drop".to_string(), "swap".to_string(), "over".to_string(), "rot".to_string(), // ... 200+ more entries "weave.close".to_string(), ] } ``` ## Impact - **Duplication**: This list must be synchronized with: - Compiler builtins - Stack effects definitions (see related issue) - Documentation - **Maintenance burden**: Adding a new builtin requires updating 3+ locations - **Error-prone**: Easy to forget to add completions for new words - **Stale documentation**: Completion descriptions can drift from reality ## Related Issues This is closely related to the stack effects extraction issue - both should ideally share a single source of truth for builtin words. ## Proposed Solution ### Option 1: Generate from compiler The compiler already knows all builtins. Export this list and consume it in the REPL: ```rust // crates/compiler/src/builtins.rs pub const BUILTINS: &[BuiltinDef] = &[ BuiltinDef { name: "dup", effect: "(a x -- a x x)", category: Category::Stack }, BuiltinDef { name: "drop", effect: "(a x -- a)", category: Category::Stack }, // ... ]; // crates/repl/src/completion.rs fn builtin_completions() -> Vec<String> { compiler::builtins::BUILTINS.iter() .map(|b| b.name.to_string()) .collect() } ``` ### Option 2: External data file ```toml # builtins.toml [[builtins]] name = "dup" effect = "(a x -- a x x)" category = "stack" description = "Duplicate top of stack" ``` Build-time codegen creates both compiler definitions and REPL completions. ### Option 3: Query LSP for completions If the LSP server already provides completions, remove the hardcoded fallback entirely and rely on LSP. ## Files Affected - `crates/repl/src/app.rs` (lines 1327-1535) - Potentially `crates/compiler/src/builtins.rs` (new) - Potentially build script or data file ## Acceptance Criteria - [ ] Single source of truth for builtin word list - [ ] Adding new builtin requires change in exactly one place - [ ] REPL completions automatically include all compiler builtins - [ ] Remove 200+ lines of hardcoded strings ## Labels refactor, technical-debt, medium-priority

navicore commented

2026-01-10 03:00:28 +00:00

(Migrated from github.com)

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