REPL state management relies on hard-coded delays and lacks error awareness

[midhunann]

Location

src/repl.ts (approx. lines 37–62)

---

Problem

The current REPL state management assumes that commands complete successfully after fixed delays. This makes module loading and evaluation fragile and non-deterministic, especially on slower systems or when compilation errors occur.

---

Issues Identified

• REPL commands rely on fixed delays (1000ms, 200ms, 300ms) to assume completion.
• There is no verification that a module actually loaded successfully.
• Errors produced by GHCi (compile or runtime) are not detected or surfaced.
• Internal module tracking adds modules even if loading fails.
• Module unloading or failed reloads are not reflected in tracked state.
• Terminal visibility is used as a synchronization mechanism, which is unreliable.

---

Why This Is a Problem

• Fixed delays behave differently across machines and system load.
• Failed module loads can appear “successful” to the extension.
• Users do not receive clear feedback when compilation fails.
• Internal REPL state can become inconsistent with actual GHCi state.
• Makes future features (function listing, per-module execution) harder to build reliably.

---

Expected Behavior

• REPL interactions should be synchronized based on actual completion, not timeouts.
• Module loads should only be recorded if they succeed.
• Errors from GHCi should be detectable and made available to the extension.
• Internal state should accurately reflect what is loaded in the REPL.
• Behavior should be consistent across macOS, Linux, and Windows.

---

Guidance (Non-prescriptive)

Contributors working on this issue may want to explore:

• More deterministic ways of detecting when a GHCi command finishes.
• Capturing and interpreting GHCi output instead of assuming success.
• Event- or output-based completion signals rather than fixed delays.
• Improving how module state is tracked when loads or reloads fail.

The exact approach and design choices are intentionally left open.

---

How to Test

1. Install the extension from VS Code (or run it via the extension host).

2. Clone the test repository:

   https://github.com/midhunann/haskell-test
   

3. Open the repository in VS Code.

4. Try loading modules and evaluating expressions in the REPL.

5. Introduce intentional syntax or type errors and observe behavior.

6. Modify and reload modules repeatedly.

7. Verify that:

   • Failed loads are detected
   • Errors are visible to the user
   • REPL state remains consistent after failures

---

Priority

Medium — this does not block basic usage, but it significantly affects reliability, correctness, and future extensibility.

Note: Come up with a solution and then after we discuss you can proceed to fix

[arjunankvig-web]

/assign

[Devpool-soc]

Alright @arjunankvig-web! Consider yourself officially assigned as now. If you are thinking, "Whoa, hold up, I didn't sign up for this," no worries, just yell "/unassign" and we can pretend this never happened. But if you are sticking around, just know your clock for this ticks out on: 2026-01-17. Don't screw it up :)

[arjunankvig-web]

I’ve implemented a deterministic fix for the REPL state management issues described above.

Key changes:

• Removed all fixed delay–based synchronization (e.g. setTimeout) from GHCi interactions.
• Introduced a centralized GhciReplManager that executes REPL commands sequentially using a queue.
• Command completion is now detected by observing actual GHCi output (prompt reappearance), not timing assumptions.
• GHCi stdout/stderr are captured and parsed to detect compile/runtime errors.
• Module load and reload state is updated only after successful command execution.
• Errors are surfaced to the user instead of being silently ignored.
• Internal REPL state is reset safely on unexpected GHCi termination.

This makes module loading and evaluation deterministic, prevents state desynchronization after failed loads or reloads, and improves reliability across slower systems and different platforms.