LIVE 2025 reviewer feedback

[cben]

(thanks to anonymous reviewers 🙏❤️! very summarized)

83A:

• hard to follow
• unclear WHAT the proposal is
• rotateRight doesn't work? (hmm, was it simply greyed out at that specific position? find clearer UX?
• Do we really need action history? Why not just mutate source with current value?
  TODO: good Q, text must acknoledge it. Perhaps pivot structure to "there is various prior art storing state & source in same way -> I propose a specific redux-like take on that" ?

prior art:

A relevant feature in prior work is colorForth's magenta variables: these refer to a point in the source code, and run-time updates to the variable change the code at that location permanently. It doesn't maintain a history, only the one single value. This is not the same, but may lead you to other related approaches. Another approach with relevant similarities, but a different ethos, is the HTML-embedded serialisation of something like TiddlyWiki, but that feels more distant than the automatic persistence of immediate data.

83B:

• flesh out further

• more operators after WRITE, JUMP?

  While there is great discussion of the fact that UI actions constitute a DSL, I would love to see further discussion on the "self-modify operator language" exposed to the application developer.

  TODO: I meant DSL at more app-specific level, consisting of things like left() and rotateRight(). need to make that clearer

• challenge "Can we truly move all mutation out of the language?" with example of long loop reassigning a variable. has a point, I'm targetting constrained kind of apps.
  TODO: I'm overly biased by redux experience; write for users who might not know it.

83C:

• brittle dependency on caret position!
• append-only approach not essential ++
  • in-place alternative might preclude the exact time-travel technique shown in the tetris example, but you could still scrub through history with undo/redo. 💡
• disagrees on value of de-functionalization
• presentation is disorganized, very note-like (💯, I wrote in a hurry)
• "Many of the details here seem directed by the write operation in specific rather than the broader notion of MVU + self-modification, which I think could use a bit more general treatment."

P.S. reviewer's "Paper summary" sections were great, see what I can steal for clearer presentation ;-)

[cben]

Hmm, am I convinced I need append-only approach? 😮🤔

---

The "WRITE() happens wherever caret is" was indeed an early kludge.
Experience with it pushed me towards having run-time "pointers" to (mutable) place in source, which IIRC I don't explain enough in essay?
And part of my motivation was simulating distinct "message recievers". I.e. effectively mutable objects!

I should admit moving mutation out of "the language" into "the IDE" is very fuzzy, what with me dragging IDE concepts into the language 🫠.
If anything, it's less about theoretical purity and more pragmatic "functional core, imperative shell" balance — pushing that shell out one more step.