The actual mechanism of the terraced scan is agnostic by design about what codelets actually do—there's no inherent restriction on the actions they can take. You're perfectly free to use working data structures that aren't the Workspace, and at some point I'll be exploring that. It might be nice to have some other data structure being built, a database or a document or maybe a code structure or something.

But as I've been actually exercising it and learning how I prefer to design codelets and the ecosystems they cooperate in, I'm starting to converge on some best practices, or at least practices I find easiest to work with. One of them has been to group the actions taken by codelets into "fff actions" (fizzle/fail/fire actions taken when the codelet terminates). Those started out as just a list of which units should be killed; if a spark fizzles, then the spark unit needs to be deleted. And if a bond is dissolved, then obviously the bond unit needs to be deleted.

Then I decided I'd add more options to the fff action handler, and ended up with a list of supported actions that include promotion to a new type, deletion, increment of frustration, relief of frustration, and so on.

The Workspace actually has an event notification mechanism. This makes it easy for displays to get notification of what they should be displaying. I'd built a grouping mechanism into it that would flag certain events as being components of one higher-level event. So for instance, when we glom a bond group into a unit, we do a lot of different things—delete the bonds, create a glom, add the letters to the glom—and the display should know that the bond being deleted is being deleted to make room for a glom, because we'll display that differently in an animation.

It would be nice if the fff actions could constitute a group, except not everything that constitutes a group can be done in the fff actions, chief of which is that the fff actions can't create a new unit, like a bond. One of the reasons I came up with formally defined Workspace moves, actually, is that the move handlers are just arbitrary code and can therefore create a new unit and then bind things to it in a single call.

But I still want to have the fff actions available if I'm prototyping a codelet that doesn't have a well-defined move yet. So I've added "start_move" and "end_move" to the Workspace to issue start-group and end-group notifications. The only difference is that only one move can be active at a time—this allows us to compose moves without event notification subscribers having to keep track of a group stack. And the final call to fff-action also ends the current move. From a practical standpoint, that gives me the option of defining something like informal moves in a codelet prototype—I can start the move, do whatever I need to do, then allow the codelet to fire (or fizzle or fail) to end the move. Later, once I trust it, I can move all that out into a formally defined move to simplify the codelet.

That lets me kind of gently ease into a codelet ecosystem's development, starting with arbitrary anything-goes code, then naming and grouping the move logic, and finally pulling it out into formally defined moves. I suspect I'll gradually start thinking in terms of moves first as I gain more experience, but I like leaving options.