A scanner error escapes as an interpreter error and takes the REPL with it #4

Open
opened 2026-08-02 19:04:11 -04:00 by tachikoma · 0 comments
Collaborator

Source: TODO.md §8 (at 9151438)

The boundary between a script's error and the host's error sits around parsing and around
interpret(), but not around scanning. akbasic_runtime_process_line_repl() and
akbasic_runtime_process_line_run() both call akbasic_scanner_scan() under a bare PASS
(src/runtime.c:825 and :921), so any error the scanner raises leaves step() as an
interpreter error.

The reachable one is the token ceiling:

$ printf 'PRINT 1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1\n' | ./build/basic
src/scanner.c:add_token:87: 515 (Out Of Bounds) : Line 0 has more than 32 tokens
... eight more frames ...
akbasic terminated on an unhandled error 515 (Out Of Bounds)

Exit status 1, a stack trace on stderr, and the prompt gone -- for a line a person typed. An
embedding host is handed a context for what is plainly the script's mistake, which is what goal 3
exists to prevent.

It should print ? N : PARSE ERROR Line N has more than 32 tokens and stop the run, exactly as a
parse error does two lines further down.

The fix is the same ATTEMPT/HANDLE_DEFAULT/akbasic_runtime_error() wrapper already sitting
around akbasic_parser_parse() in both functions, moved up to cover the scan.
Three call sites
to check, because process_line_runstream() has the same bare PASS and its answer may want to
differ
: a bad line arriving from a file mid-load is not the same situation as one typed at a
prompt.

Wants a test in tests/scanner_tokens.c asserting the error line rather than the raised status,
and one in tests/housekeeping_verbs.c asserting the REPL survives it.

Files: src/runtime.c:825,921, tests/scanner_tokens.c, tests/housekeeping_verbs.c


Filed by Tachikoma (Claude Code, Opus 5, 1M context)

**Source:** TODO.md §8 (at 9151438) The boundary between a script's error and the host's error sits around parsing and around `interpret()`, **but not around scanning.** `akbasic_runtime_process_line_repl()` and `akbasic_runtime_process_line_run()` both call `akbasic_scanner_scan()` under a bare `PASS` (`src/runtime.c:825` and `:921`), so any error the scanner raises leaves `step()` as an interpreter error. The reachable one is the token ceiling: ``` $ printf 'PRINT 1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1\n' | ./build/basic src/scanner.c:add_token:87: 515 (Out Of Bounds) : Line 0 has more than 32 tokens ... eight more frames ... akbasic terminated on an unhandled error 515 (Out Of Bounds) ``` **Exit status 1, a stack trace on stderr, and the prompt gone -- for a line a person typed.** An embedding host is handed a context for what is plainly the script's mistake, which is what goal 3 exists to prevent. It should print `? N : PARSE ERROR Line N has more than 32 tokens` and stop the run, exactly as a parse error does two lines further down. **The fix is the same `ATTEMPT`/`HANDLE_DEFAULT`/`akbasic_runtime_error()` wrapper already sitting around `akbasic_parser_parse()` in both functions, moved up to cover the scan.** Three call sites to check, because `process_line_runstream()` has the same bare `PASS` and **its answer may want to differ**: a bad line arriving from a file mid-load is not the same situation as one typed at a prompt. Wants a test in `tests/scanner_tokens.c` asserting the error *line* rather than the raised status, and one in `tests/housekeeping_verbs.c` asserting the REPL survives it. **Files:** `src/runtime.c:825,921`, `tests/scanner_tokens.c`, `tests/housekeeping_verbs.c` --- Filed by Tachikoma (Claude Code, Opus 5, 1M context)
tachikoma added this to the 0.1.x milestone 2026-08-02 19:04:11 -04:00
tachikoma added the defectblast-radius:highstatus::grooming labels 2026-08-02 19:04:11 -04:00
Sign in to join this conversation.