peraino@gmuvax2.gmu.edu (Bob Peraino) (01/29/91)
>Just put some unique object onto the stack at the beginning of your >program--one that you never use otherwise--and then at the end of >the program, just execute this 'clear to mark' program: > >CTOM ><< WHILE <your object here> SAME NOT DO END >> . . >Michael C. Grant Nice idea, but.. I simply cannot imagine how a program can be written to have no idea what it has thrown up on the stack. peraino@gmuvax.gmu.edu
madler@pooh.caltech.edu (Mark Adler) (01/29/91)
>> I simply cannot imagine how a program can be written to have no idea >> what it has thrown up on the stack. I'm sure you can come up with such an example, but aside from that, consider the difficulty of tracking the stack usage at all program exit points, especially error exits. 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. Then, finally, reconsider the clear-to-mark idea, and you will breath a sigh of relief if you had been considering all those other hassles. Mark Adler madler@pooh.caltech.edu
TNAN0@CCVAX.IASTATE.EDU (01/29/91)
Ok, here's one peraino... << DO RAND UNTIL DUP .999 > END >> Be careful not to use drop end. Assume all values are needed until completion of the program (let's say they would be used in the event that the last value was exactly .999)... This is a simple (and useless) example of a problem that can plague many program writers... Sometimes, a variable number of stack values can be produced each run through a program. Unless the program keeps count, it cannot know how many of its own objects are on the stack. Using DEPTH and DROPN is MUCH simpler than keeping count on the stack... By the way, "drop end" 8 lines up should be "DROPN"... ---Xeno
edp@jareth.enet.dec.com (Eric Postpischil (Always mount a scratch monkey.)) (01/29/91)
In article <3306@gmuvax2.gmu.edu>, peraino@gmuvax2.gmu.edu (Bob Peraino) writes: > I simply cannot imagine how a program can be written to have no idea >what it has thrown up on the stack. ROOT is an example. The user gives root some arguments that include an object to be evaluated. ROOT evaluates that object repeatedly for different values of some variable. Sometimes an error is generated. ROOT must trap this error and clean up the stack. To be sure, CLEAR is not necessary; remembering the initial stack depth is sufficient. Another reason CLEAR might be desirable is when speed is important. -- edp (Eric Postpischil) "Always mount a scratch monkey." edp@jareth.enet.dec.com
peraino@gmuvax2.gmu.edu (Bob Peraino) (02/01/91)
>>> I simply cannot imagine how a program can be written to have no idea >>> what it has thrown up on the stack. > >I'm sure you can come up with such an example, but aside from that, consider >the difficulty of tracking the stack usage at all program exit points, >especially error exits. That is not difficult. > 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? Either the code is logically correct, or it isn't. And if its logically correct, then everything is accounted for. > Then, finally, reconsider >the clear-to-mark idea, and you will breath a sigh of relief if you had been >considering all those other hassles. > >Mark Adler >madler@pooh.caltech.edu I'm sorry, but I greatly disagree with you. It isn't a "hassle" for me to write code that works properly. Everything is on the stack for a reason, and if ANYTHING is not accounted for, then the code is flawed. I write code all the time that does nothing but stack manipulation, for speed. And when it finishes, (even recursive code) the stack is exactly the way it was, and everything was account for. (I know, I know, never end a sentence with a preposition). I don't mean to sound condescending, but if you're writing code and cannot keep track of what you're doing with the stack, then you are writing code that you yourself do not understand. peraino@gmuvax.gmu.edu
bson@rice-chex.ai.mit.edu (Jan Brittenson) (02/01/91)
In a posting of [29 Jan 91 05:30:00 GMT] TNAN0@CCVAX.IASTATE.EDU writes: > Ok, here's one peraino... > > << DO RAND UNTIL DUP .999 > END >> > > Assume all values are needed until completion of the program (let's > say they would be used in the event that the last value was exactly I'm not sure exactly what I'm arguing and why, but hey... This wouldn't work, as you wouldn't have any idea how many random numbers you had left on the stack. Not without a counter, in which case you know how many to drop if you decide not to use them. To illustrate my point, assume that at the beginning the stack looks like this - am I the only one to prefer the good ol' FIX 4? :-) 3: "ABC" 2: 0.1000 1: 0.4711 Further assume that after the loop above exits, the stack looks like this: 7: "ABC" 6: 0.1000 5: 0.4711 4: 0.rand 3: 0.rand 2: 0.rand 1: 0.9990 A counter is need, and one way is to keep it on top of the stack: << 0 DO 1 + RAND SWAP UNTIL OVER .999 >= END >> Thus you would be left with: 8: "ABC" 7: 0.1000 6: 0.4711 5: 0.rand 4: 0.rand 3: 0.rand 2: 0.9990 1: 4.0000 Then we're compatible with DROPN, ->ARR, ->LIST, etc. You can also feed it to a program: << -> Nelem << 1 Nelem START GOBBLE NEXT >> >> I'm not saying CLEAR is _never_ necessary... just that it sort of defeats the purpose of a stack to clear it. -- Jan Brittenson bson@ai.mit.edu ;; "Make sure the brain is connected before the mouth is started."
edp@jareth.enet.dec.com (Eric Postpischil (Always mount a scratch monkey.)) (02/02/91)
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
s872607@minyos.xx.rmit.oz.au (George Tzanatos) (02/07/91)
Why count what you have put on the stack? Isn't it easier to store the size of the stack at the start of the program, then do a... DEPTH InitialStackSize - DROP George.