We've now reached a point where we need to start thinking of error handling,
and tests for error handling. The top-level has `stop`, but that's really
just for working with Unix's exit(). Here we have the opportunity to bake
errors into the trace. Which might also be a good opportunity for fleshing
out the UX for the trace.
The text buffer can now shrink, which means we need to be careful to erase
the old location of the cursor. Just clear screen before render each time.
Which means we need to be more efficient with our rendering.
Some settings in my vimrc, now that I plan to move closer to Lisp:
inoremap <buffer> [ (
inoremap <buffer> ] )
inoremap <buffer> ( [
inoremap <buffer> ) ]
It might be too ambitious for an initial Mu system, and I also want to
watch my novelty budget. I also have great doubts about the ability of
this live-updating postfix system to scale to interesting programs. Conditionals,
loops, multi-line functions, all this requires further work.
Instead, I'm going to recenter around Mu's original goals:
- saying no to most features
- encouraging/teaching testing
- traces as a unifying metaphor
In particular, instead of a live-updating system, the new debug loop will
be:
- generate a trace
- browse the trace
- modify the program
- generate a trace
- ...
The only persistence we'll need here is a way to track what the programmer
has drilled into in the trace. That might have some commonalities with
the old system of expanded words.
Bug in code-size check.
It costs 18 bytes in the boot sector to load 2 tracks of disk (63KB). At
that rate I can load 6 more tracks before I need to perform the drudgery
again of recalculating offsets.
Kartik K. Agaram