[m-rev.] for review: implement undo for declarative debugger

[Ian MacLarty]

On Tue, 26 Jul 2005, Mark Brown wrote:

> On 26-Jul-2005, Ian MacLarty <maclarty at cs.mu.OZ.AU> wrote:
> > On Tue, 26 Jul 2005, Mark Brown wrote:
> >
> > > On 26-Jul-2005, Ian MacLarty <maclarty at cs.mu.OZ.AU> wrote:
> > > > --- doc/user_guide.texi	17 Jun 2005 10:13:55 -0000	1.439
> > > > +++ doc/user_guide.texi	26 Jul 2005 02:04:16 -0000
> > > > @@ -4100,6 +4100,11 @@
> > > >  @item skip
> > > >  Skip this question and ask a different one if possible.
> > > >  @sp 1
> > > > + at item undo
> > > > +Reset the state of the declarative debugger to the state it was in before the
> > > > +last `yes', `no', `inadmissible', `trust' or `skip' answer was given or
> > > > +the last subterm was marked, whichever was most recent.
> > > > + at sp 1
> > >
> > > What happens if you give the `undo' command twice in succession?  The
> > > documentation should be clearer on this point.
> > >
> >
> > Isn't it clear that if the state of the declarative debugger has been reset
> > to what it was before the previous answer, then issuing another undo will
> > reset the state of the declarative debugger to what it was before the
> > previous-previous answer?
>
> Not entirely.  It depends on how you interpret the word "last" in the
> description.  Is the sequence of commands from which we select the "last"
> considered part of the state of the debugger (and is therefore also reset),
> or not?  If you implement a "redo" command, for example, you could say that
> it reverses the effect of the last undo command, but that would be "last"
> in a different sense.
>

Are you saying that people might interpret the description as meaning
undo is idempotent?
Or are you saying they may think two successive undos would cancel each other
out.
The fact that I say the state is reset to what it was before the last
`yes', `no', `inadmissible', `trust', `skip' or `mark' excludes the possibility
that two undos would cancel each other out (since `undo' is not included in
this list).

Ian.

--------------------------------------------------------------------------
mercury-reviews mailing list
post:  mercury-reviews at cs.mu.oz.au
administrative address: owner-mercury-reviews at cs.mu.oz.au
unsubscribe: Address: mercury-reviews-request at cs.mu.oz.au Message: unsubscribe
subscribe:   Address: mercury-reviews-request at cs.mu.oz.au Message: subscribe
--------------------------------------------------------------------------