Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!jarthur!sburke
From: sburke@jarthur.Claremont.EDU (Scott Burke)
Newsgroups: comp.sys.handhelds
Subject: Re: CLEARing stack
Keywords: CLEAR
Message-ID: <10538@jarthur.Claremont.EDU>
Date: 29 Jan 91 06:51:14 GMT
References: <10535@jarthur.Claremont.EDU> <1991Jan29.044750.1789@csn.org>
Organization: Harvey Mudd College, Claremont, CA 91711
Lines: 47


Response to ian:

So far, in all the code I have written, there have been no unavoidable
places where it was necessary to provide stack access to the user.  Therefore
the initial stack remains pure and should be preserved.  I have never found
a need for the HALT statement, and regard its use as non-intuitive and to be
avoided.  There is a case, I admit, where it _makes sense_ to provide stack
access in one of my programs, but in that case, I create a single parameter
file and quit the program; if the user re-executes the library, and if a 
parameter file of the correct format exists, then the user is provided an
additional menu choice to return to where they were before.

You also discuss additions and subtractions to the stack.  What I mean by
that is (to use another HP example) the case where the user runs the Periodic
Table and presses the ATWT key, thereby leaving the Atomic Weight (a tagged
object) on the stack.  The stack depth pointer must be updated, because 
otherwise, when the restoration routine (basically DEPTH counter - DROPN)
runs, it will obliterate the desired atomic weight.  Does this make sense?
As for deleting stack entries, unless the user is given access with HALT, 
they cannot delete entries, because the stack access in the Interactive Stack
in the INPUT/EDIT menu is crippled and the delete key is not functional.
Obviously my code could eat entries on the stack, but if it did so, i also
would pity it.  That is not a worry.

Again, the reason for having a current depth pointer is to know how many
items to drop at termination.  It is not possible in complex code to always
know how many temporary items are on the stack at any given time unless
absolutely every calculation takes place through local variables, making
use of STO+, etc., and not leaving more than 1 or 2 items on the stack at
any time.  That is one solution, but it is by far and away the slowest one.

I guess the key point I was trying to make is that you have to enable the 
user to copy to the stack an arbitrary (and therefore unknowable in advance)
number of values or whatever, by means of a ->STK operation.  To track this,
it is either necessary to append those values to the original stack stored
in a list (which is not desirable for reasons i mentioned in the previous 
post) or to just place the desired values on the stack and increment the
depth pointer.  It is therefore crucial to not allow the user to break out of
any code before it updates the depth pointer and propagates that change in
depth upwards to any parent routines.  Thus the IFERRs.

I think I have answered your criticisms.

Scott.

sburke@jarthur.claremont.edu