# Interpreter Complexity Analysis Report
## Executive Summary
PMAT analysis reveals critical complexity violations in the REPL interpreter that violate Toyota Way quality principles:
### Critical Violations Found
| `Repl::evaluate_expr` | **209** | **541** | 649 | ❌ CRITICAL |
| `Value::format_dataframe` | **69** | **113** | ~150 | ❌ HIGH |
| `Value::fmt` | **66** | **104** | ~200 | ❌ HIGH |
| `Repl::evaluate_binary` | **46** | ~80 | ~100 | ⚠️ WARNING |
| `Repl::save_session` | **45** | ~75 | ~100 | ⚠️ WARNING |
**Thresholds:**
- Maximum allowed cyclomatic complexity: **50** (recommended: 20)
- Maximum allowed cognitive complexity: **30**
- Maximum function length: **100 lines**
## Root Cause Analysis
### 1. evaluate_expr (Lines 818-1467)
The main interpreter dispatch function handles 30+ expression types in a single massive match statement:
- Each branch contains inline evaluation logic
- Method calls alone span 200+ lines (lines 1139-1355)
- No helper functions to delegate complexity
- Deeply nested control flow (up to 8 levels)
### 2. Method Call Handling
The MethodCall branch contains complete implementations for:
- List methods: map, filter, reduce, sum, head, tail, reverse (150+ lines)
- String methods: len, upper, lower, trim, split (50+ lines)
- Numeric methods: abs, sqrt, sin, cos, tan, log (50+ lines)
- DataFrame methods (placeholder)
## Refactoring Strategy
### Phase 1: Extract Method Handlers (Immediate)
Create focused helper methods with complexity < 15:
```rust
// Before: 200+ lines in one branch
ExprKind::MethodCall { receiver, method, args } => {
// 200+ lines of nested if-else chains
}
// After: Delegate to type-specific handlers
ExprKind::MethodCall { receiver, method, args } => {
let receiver_val = self.evaluate_expr(receiver, deadline, depth + 1)?;
match receiver_val {
Value::List(items) => self.evaluate_list_methods(items, method, args, deadline, depth),
Value::String(s) => self.evaluate_string_methods(s, method, args),
Value::Int(n) => self.evaluate_int_methods(n, method),
Value::Float(f) => self.evaluate_float_methods(f, method),
_ => bail!("Method {} not supported", method),
}
}
```
### Phase 2: Extract Control Flow Helpers
- `evaluate_for_loop()` - Handle for loop logic (currently 40+ lines inline)
- `evaluate_while_loop()` - Handle while loop logic (currently 30+ lines inline)
- `evaluate_block_expression()` - Handle block evaluation
### Phase 3: Extract Collection Helpers
- `evaluate_list_literal()` - Build list values
- `evaluate_tuple_literal()` - Build tuple values
- `evaluate_range_literal()` - Build range values
## Implementation Plan
### Step 1: Add Helper Methods (lines to add after current evaluate_expr)
```rust
impl Repl {
// === Method evaluation helpers (complexity < 15 each) ===
fn evaluate_list_methods(&mut self, items: Vec<Value>, method: &str, args: &[Expr], deadline: Instant, depth: usize) -> Result<Value>
fn evaluate_list_map(&mut self, items: Vec<Value>, args: &[Expr], deadline: Instant, depth: usize) -> Result<Value>
fn evaluate_list_filter(&mut self, items: Vec<Value>, args: &[Expr], deadline: Instant, depth: usize) -> Result<Value>
fn evaluate_list_reduce(&mut self, items: Vec<Value>, args: &[Expr], deadline: Instant, depth: usize) -> Result<Value>
fn evaluate_string_methods(&self, s: String, method: &str, args: &[Expr]) -> Result<Value>
fn evaluate_int_methods(&self, n: i64, method: &str) -> Result<Value>
fn evaluate_float_methods(&self, f: f64, method: &str) -> Result<Value>
}
```
### Step 2: Update evaluate_expr
Replace the massive match arms with calls to helper methods.
### Step 3: Validate
- Run all tests: `cargo test --test interpreter_core_reliability`
- Re-run PMAT: `pmat analyze complexity --file src/runtime/repl.rs`
- Verify all functions < 50 complexity
## Success Criteria
✅ All functions have cyclomatic complexity < 50
✅ All functions have cognitive complexity < 30
✅ No function exceeds 100 lines
✅ All 34 interpreter tests pass
✅ No performance regression
## Conclusion
The current interpreter violates Toyota Way quality standards with a cyclomatic complexity of 209 (4x the allowed limit). The refactoring plan will:
1. Reduce evaluate_expr complexity from 209 to < 30
2. Create 15+ focused helper methods, each with complexity < 15
3. Improve code maintainability and testability
4. Enable future optimizations
This refactoring is **MANDATORY** before any new features per Toyota Way principles.