Newsgroups: rec.arts.int-fiction
Path: nntp.gmd.de!news.ruhr-uni-bochum.de!news.rhrz.uni-bonn.de!RRZ.Uni-Koeln.DE!news.gtn.com!osn.de!noris.net!blackbush.xlink.net!tank.news.pipex.net!pipex!arclight.uoregon.edu!nntp.primenet.com!howland.erols.net!netcom.com!erkyrath
From: erkyrath@netcom.com (Andrew Plotkin)
Subject: Re: [Z-machine] multiple undo
Message-ID: <erkyrathDxFruz.831@netcom.com>
Organization: NETCOM On-line Communication Services (408 261-4700 guest)
X-Newsreader: TIN [version 1.2 PL1]
References: <ant3011230b070RF@arnod.demon.co.uk> <erkyrathDwyvw2.7F6@netcom.com> <50hmfb$oes@mars.worldonline.nl> <erkyrathDx63qq.M3n@netcom.com> <50qrlg$nai@news.dx.net>
Date: Sun, 8 Sep 1996 22:59:23 GMT
Lines: 44
Sender: erkyrath@netcom5.netcom.com

Greg Falcon (professor.falken@pnx.com) wrote:
> erkyrath@netcom.com (Andrew Plotkin) wrote:

> >I ain't seeing what you're claiming. (I'm looking at the 0.2 spec 
> >document.) @save_undo "saves the game into a cache of memory held by the 
> >interpreter." @restore_undo "restores the state saved to memory by 
> >@save_undo... The behavior of @restore_undo is unspecified if no 
> >@save_undo has previously occurred." But it doesn't say that the cache is 
> >invalidated after the @restore_undo completes. If the cache is reloaded 
> >with an earlier state, such that a further @restore_undo will restore 
> >*that* and return a success value, is this contrary to the spec?

> From the 0.2 spec:

>  6.1.1.2 An internal saved game for "undo" purposes (if there is one)
>  is not part of the state of play.  This is important:  if a saved
>  game file also contained the internal saved game at the time of
>  saving, it would be impossible to undo the act of restoration.  It
>  also prevents internal saved games from growing larger and larger as
>  they include their predecessors.

So? This does not say that the interpreter cannot put additional 
information alongside that saved-game state. The interpreter always has 
gobs of private information.

> >If this is an extension to the Z-machine, then I propose it. 

> I don't know.  The point about being unable to UNDO a RESTORE is worth
> thinking about.

I did not propose that the Z-machine spec be changed to *require* 
multiple undo. I said that the Z-machine should leave it up to the 
interpreter to decide when an undo request is fulfillable, and when it 
isn't. And that it test this using the already-defined mechanism of the 
return code of the @restore_undo opcode.

And I still think the Z-spec is already compatible with this philosophy.

--Z

-- 

"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."
