Re: LOGO-L> UNDO -- third try

[Chuck Shavit <CShavit@MagicSquare.com>]

Hummm, you're talking about a universal UNDO.  It's a bit of a purist
approach. In that way, it's easy to show that no UNDO is ever possible,
even in the simplest cases.  For example, I show a friend how I can draw
some lines, and I make a mistake.  As I do that, my friend gets an idea of
a brand new programming concept.  I undo the last command, but the idea in
my friend's mind cannot be erased.

I guess the UNDOability of life is a rather trivial philosophical concept.

But practical LIFO-style UNDO is easy, as Charles T. Smith writes - just
save the state of LOGO when it starts (presumably, with the variables and
procedures spaces clear), and log the user's actions.  Then for UNDO,
simply restore the initial state and play back all but the last user
inputs.  For an extra purity, rename the UNDO command (I don't have
suggestions) to make it clear that we are re-running commands and not
UNDOing the world.  This renaming is especially needed if you don't want to
log all the user's inputs, e.g., mouse clicks read by the user's program.

As for saving the internal states as you write in the last pa - that is an
optimization for avoiding having to run everything from the top and logging
all the user's inputs.  It's not necessarily the best optimization, but it
is certainly one the hardest to implement.  An easier way is to store
(possibly incremental) checkpoints, and then roll-back to the last
checkpoint and play the n-1 commands from there on.

But, I think that what the users really want is not a LIFO-style UNDO, but
rather an ability to go back and change what they did - modify arguments,
add and delete commands, replace a series of almost identical commands with
a loop or a procedure, etc.  All that is needed is storing the history
file, and making it available in an editor.  The big benefit of this
approach is that it will encourage people to review what they did and
improve it, thus blurring the difference between "programming" and
"experimenting".

Chuck Shavit

Brian Harvey wrote: 

 >"Charles T. Smith" <mrchuc@math.fan.org> writes:
 >>I discussed this feature a couple of years ago (before I had had a chance
 >>to use it much) with Michael Tempel. He pointed out then that it could be
 >>implemented in Logo easily by keeping all the commands in a Logo list and
 >>then butlast-ing the list and running it again.
 >
 >No, I don't think that's true.  It's true if all you do is draw lines
 >on the screen, but some things change the state of the world in a way
 >that's not so easy to back up.
 >
 >Perhaps the most obvious example:  Imagine that you have a floor
 >turtle -- that is, an actual physical robot with a pen, sitting on
 >a big piece of paper on the floor.  There is no way to "undo"
 >drawing a line!
 >
 >Other examples: you've written something into a file; you've sent
 >a message to someone over the Internet; you've exited Logo!  :-)
 >
 >What makes a reasonable approximation to undo hard, though, are the
 >internal changes:  You've modified a variable, or redefined a
 >procedure.  In order to be able to undo these, you have to keep a
 >history of all old values of things.  And since the undone instruction
 >might invoke a user-defined procedure, Logo would have to be ready to
 >undo an arbitrarily complicated series of instructions within that
 >procedure.  (It might, for example, invoke itself recursively 1000
 >times, modifying a different variable each time.) This is why a lot
 >of extra memory might be used, to remember all that history.



---------------------------------------------------------------
Please post messages to the Logo forum to logo-l@gsn.org.  Mail
questions about the list administration to logofdn@gsn.org.  To
unsubscribe send    unsubscribe logo-l    to majordomo@gsn.org.