At 8:29 AM 1/20/99, Andrew C. Greenberg wrote:

>The devil here *is* in the details, and before we start asking Squeak 
>Central to provide us with a ubiquitously portable, super-efficient, highly 
>concurrent system for making the creation of absolutely undoable completely 
>reversable and fail-stop GUI application trivial, let's really get down to 
>defining what, if anything, that really means.

I agree with this, and with Andrew's main argument.  However, I will
quibble about some details.


>The very notion of 
>an "undo" facility defies definition outside the context of specific 
>applications.  Clearly, undo can be defined at varying degrees of 
>granularity and completeness.  (e.g. what is the smallest undoable 
>"operation"; what operations can be undone; how much state must be saved 
>between operations to undo; how many layers of state saves are necessary). 

Undo is always application dependent, but the system can still say a lot
about it.  It can say that there are "commands" that can be done, undone,
and redone.  It can manage a stack of such commands, and provide ways to
view that stack and to operate on it.  Applications have to define their
own commands, of course, as well as how to do, undo, and redo them.  This
idea has been around since at least MacApp, and I've implemented it in
Smalltalk several times and have wished it were part of the standard.


>The thing is this: I don't have a PDP-11 to front-end my iMac.  I have only 
>the iMac on this desktop.  Another process watching this processor is 
>expensive -- it costs something.  Everytime I stick something out there to 
>watch something else, it costs something.  The more of that created by my 
>"architects," the less I can remove, and the less I can add myself.

But suppose Smalltalk had built into it the ability for one image to
operate on another.  Then it you got into trouble with one image, you
could call up another to operate on it.  If this were done at the VM
level then it would be hard to break.  It is possible that there would
be no run-time cost for providing this facility if you weren't using it.
Thus, you would get the equivalent of a process watching your processor
without it costing you anything, at least in terms of run-time.

-Ralph