Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!elroy.jpl.nasa.gov!sdd.hp.com!decwrl!deccrl!news.crl.dec.com!shlump.nac.dec.com!jareth.enet.dec.com!edp
From: edp@jareth.enet.dec.com (Eric Postpischil (Always mount a scratch monkey.))
Newsgroups: comp.sys.handhelds
Subject: RE: CLEAR-TO-MARK code.
Keywords: hp48
Message-ID: <19696@shlump.nac.dec.com>
Date: 1 Feb 91 16:19:39 GMT
References: <3331@gmuvax2.gmu.edu>
Sender: newsdaemon@shlump.nac.dec.com
Reply-To: edp@jareth.enet.dec.com (Eric Postpischil (Always mount a scratch monkey.))
Organization: Digital Equipment Corporation
Lines: 38

In article <3331@gmuvax2.gmu.edu>, peraino@gmuvax2.gmu.edu (Bob Peraino)
writes:

>>  And then consider program maintainability (i.e.
>>changing the program).  And also consider having to keep track, at runtime,
>>of variable size objects decomposed on the stack.
>
>     I really don't understand that; if your code is logically correct, how
can
>it have stuff just lying around on the stack, and not know why its there, or
>how much is there?

Please, your question was answered and you simply ignored it.  One answer is
given above:  variable-size objects decomposed on the stack.  I gave another
answer in a separate posting:  the example of ROOT, which must call a totally
unknown routine and be able to deal with errors occurring in that routine. 
E.g., if ROOT is given 'X+SQRT(X-5)' to solve for, it might, while searching for
solutions, evalute the expression at X=4.  This will generate an error.  ROOT
traps this error, using IFERR or something equivalent.  But then it does not
know how many things were pushed on the stack before the error occurred.  It has
to have another way to clean up and continue to search for solutions.


>> If the user breaks out of the code
>
>     A better way to word it may be, " how it would be possible that the
>PROGRAM doesn't know what's on the stack". Of course, ATTN is a bit of an
>exception. If you cancel a running program, that "image" as I like to call
>it, or program, IS NO MORE.

That is not true in the general case.  A good program may have code to trap an
attention and perform clean-up -- including restoring the stack to its original
state given the unknown state it was left in by the interruption.


				-- edp (Eric Postpischil)
				"Always mount a scratch monkey."
				edp@jareth.enet.dec.com