Ok, so I did a survey of the design in one of the applications I built, and I'm pretty convinced I could move to a completely-declarative model, with not *too* much effort.
One thing that baffles me though, is how you would go about implementing undo/redo functionality.
In my current application, just about everything can be undone/redone, with a theoretically infinite list of snapshots. I had to put in some weird mechanisms to shield the undo/redo system from saving state *too* often, like for example if the user is dragging an object on the screen, it only remembers where it was and where it ended up, not the whole path.
It's unbelievably simple to implement this in our imperative world...the undo/redo system (which, incidentally, in written in user-land and requires no support from the architecture) listens for changes in the specified slots, records everything when they change, and when you tell it, will walk the stack and publish saved data at a later time.
Obviously, when you look at most of the "core" data slots in my application, you'll find at least three publishers: the thing that really calculates what it should be at runtime, and then undo, and redo.
How do you solve this in Cells? It sounds like it would be really annoying to have to write "dispatch" slots that marshall the three different possible values for every cell that falls into this pattern...but I guess that's what macros are for.
What about integrating it into the Cells engine itself? I mean, since Cells is declarative, theoretically you should be able to record the value of all the independent cells (the "roots" of your DAG of slot dependencies) and then just reset them all accordingly to get the whole system into the same state as it was...right?
Thanks for your comments...