cloos@acsu.buffalo.edu (James H. Cloos) (01/25/91)
In article <25590090@hpcvra.cv.hp.com.> billw@hpcvra.cv.hp.com. (William C Wickes) writes: >I hate to complain about an otherwise nice program, but... > >Using CLEAR is a nasty thing to do to an unsuspecting 48. IMHO, any >program should be able to clean up after itself without trashing stack >objects that it didn't put there. And I shouldn't have to read a >program's listing to figure out how to defend against its side >effects. > >Bill Wickes >HP Corvallis Just want to agree with this opinion. As someone once put it, when discussing another stack-based system: DON'T POP WHAT YOU DIDN'T PUSH! (author forgotten [SIGH].) I would point out that I just saw another program here that uses CLEAR, even to the point of excessiveness. Different discussion thread, though. -JimC -- James H. Cloos, Jr. Phone: +1 716 673-1250 cloos@ACSU.Buffalo.EDU Snail: PersonalZipCode: 14048-0772, USA cloos@ub.UUCP Quote: <>
akcs.falco@hpcvbbs.UUCP (Andrey Dolgachev) (01/26/91)
I also agree with the opinion that a program shouldn't clear the stack.
Considereing that it take virtually no effort to save the stack, it seems
senseless not to. A simple way to save the state of the calculator is to
simply store the flags, put the contents of the stack into a list, save
the list and flags as local vars, execute your program with all the
clears, flag changings, etc. you want, and then simply recall the flags
and the stack. Another thing I like about this is that if you have a
program which you are still debugging, and it happens to take which you
what you had on the stack previously as an argument accidently, it
wouldn't be a problem. Anyways, here's the open and close I use on my
programs.
\<< RCLF DEPTH \->LIST \-> flags stacklist *YOUR PROGRAM* flags STOF
stacklist LIST\-> DROP \>>
It's simple and it works, and more importantly, you won't lose anything
accidently. Hmm, come to think of it, it would be better to store the
flags and stack in global variables, so an interrupt wouldn't matter.
---Falcoakcs.dnickel@hpcvbbs.UUCP (Derek S. Nickel) (01/26/91)
In the same vein: I've seen several programs that *might* take an
argument, if there is one (or more) on the stack. Basically these crazy
programs feel that the whole stack is theirs. The stack is just another
natural resource; it must be shared. If a program needs a variable
number of arguments, then put them into a list, or supply an item count
like ->LIST).
Derek S. Nickelervin@pinbot.enet.dec.com (Joseph Ervin) (01/26/91)
>>Using CLEAR is a nasty thing to do to an unsuspecting 48. IMHO, any >>program should be able to clean up after itself without trashing stack >>objects that it didn't put there. And I shouldn't have to read a >>program's listing to figure out how to defend against its side >>effects. > >I would point out that I just saw another program here that uses >CLEAR, even to the point of excessiveness. Different discussion >thread, though. Hmm.... I just checked my Phone Number manager program and noticed that I use CLEAR in a pile of places. Apparently this is considered poort programming practice. I must agree. It seems that a simple approach to solve this problem in my Phone Number Manager would be to collapse the stack into a list upon entry of the program and save it in a temporary variable. Then at exit time, just restore the contents to the stack. This would avoid having to rewrite the routines that use CLEAR. On the other hand, it probably isn't necessary to use CLEAR at all and that the program would run fine without them. I think I just put them in by habit ( as in "it's nice to know the stack is empty upon entering a routine, so if my code is buggy it'll be easier to debug because I'll run out of operands, rather than performing operations on 'old and unrelated data' that was left on the stack"). I will put this on my list of things for the next version. Regards, >>>Joe Ervin P.S. Whoever puts my phone number manager on the goodies disk had better make sure he/she didn't copy the "garbled" V1.4 I first posted. I have since posted a corrected V1.4 which works. The "garbled" one won't even download properly to the 48SX.
bgribble@jarthur.Claremont.EDU (Bill Gribble) (01/26/91)
In article <27a06d1f:1696.3comp.sys.handhelds;1@hpcvbbs.UUCP> akcs.falco@hpcvbbs.UUCP (Andrey Dolgachev) writes: >I also agree with the opinion that a program shouldn't clear the stack. >Considereing that it take virtually no effort to save the stack, it seems >senseless not to. A simple way to save the state of the calculator is to >simply store the flags, put the contents of the stack into a list, save >the list and flags as local vars, execute your program with all the >clears, flag changings, etc. you want, and then simply recall the flags >and the stack. I agree with all the people who are saying that you shouldn't screw with the stack unless you are taking arguments; however, I don't like this idea too much. Seems like the 'real' answer would be to exercise a little programming discipline and just never clear the stack. I would think Style Rule #1 for HP programmers is to debug your programs well enough that you don't ever have to use CLEAR. What if you have some huge hunker programs and strings and graphics and .. on the stack and you don't have enough memory to save the stack to run some trivial program? Just my $.02. > ---Falco ***************************************************************************** ** Bill Gribble Harvey Mudd College, Claremont, CA ** ** bgribble@jarthur.claremont.edu Never heard of it? You're stupid. ** *****************************************************************************
mcgrant@elaine23.stanford.edu (Michael Grant) (01/27/91)
In article <19462@shlump.nac.dec.com> ervin@pinbot.enet.dec.com (Joseph Ervin) writes: >>>Using CLEAR is a nasty thing to do to an unsuspecting 48. IMHO, any >>>program should be able to clean up after itself without trashing stack >>>objects that it didn't put there. And I shouldn't have to read a >>>program's listing to figure out how to defend against its side >>>effects. >> >>I would point out that I just saw another program here that uses >>CLEAR, even to the point of excessiveness. Different discussion >>thread, though. I just thought of something that can replace CLEAR, work almost exactly LIKE clear (at least in what you WANT it to do), and yet save everyone's stack so that when they exited the progam everything was cool. It's certainly not original (it's used in postscript implementation), but noone's mentioned it here...it's 'clear to mark'. 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 >> Now, I have no idea if the syntax is correct, because I rarely use the WHILE command (if it exists). But, I think you get the idea: drop everything up to and including the mark. It's a simple program that you can include in your HOME directory or in the directory that your super-awesome-new-package-that-you- will-be-announcing-and-releasing-real-soon is kept. I hope this helps anyone who hates leaving extry stuff on the stack! Michael C. Grant
edp@jareth.enet.dec.com (Eric Postpischil (Always mount a scratch monkey.)) (01/28/91)
It has been pointed out that saving the stack is simple (DEPTH ->LIST -> local). However, this method runs the risk of losing the entire stack should the program terminate abnormally -- whether by internal error or the user pressing on/attention. Still, there are times when it is useful to restore the stack to a fixed point. For example, after running a clause in an IFERR statement, which can leave a variable number of objects on the stack, depending upon where an error is encountered or the setting of the last-arguments flag. One person suggested a clear-to-mark routine which scanned the stack looking for a particular argument. However, this routine is slow and does not distinguish between marks left by different invocations. A simpler way to accomplish this is: DEPTH -> STACKLEVEL << program >>. Anywhere in the program, the stack can be restored to the initial point with DEPTH STACKLEVEL - DROPN. -- edp (Eric Postpischil) "Always mount a scratch monkey." edp@jareth.enet.dec.com
rrd@hpfcso.HP.COM (Ray Depew) (01/29/91)
Re: storing the stack and flags before you get carried away > It's simple and it works, and more importantly, you won't lose anything > accidently. Hmm, come to think of it, it would be better to store the > flags and stack in global variables, so an interrupt wouldn't matter. > ---Falco Yes, and storing the information in global variables protects it in case the program is prematurely aborted by the user pressing the ATTN key, or by programmatic (big word!) execution of the KILL command. If you do it right, you can store the flags and stack into a self-executing list that only needs to be EVAL'ed to automatically restore both flags and stack. The synthesis of this self-executing list is left as an exercise for the interested student. While we're on the subject, would everyone agree that writing KILL into a program is also "not nice"? Regards Ray Depew IC's by Bill and Dave rrd@hpfitst1.hp.com
andrew@idacom.uucp (Andrew Scott) (01/29/91)
In article <27a06d1f:1696.3comp.sys.handhelds;1@hpcvbbs.UUCP> akcs.falco@hpcvbbs.UUCP (Andrey Dolgachev) writes: > Considereing that it take virtually no effort to save the stack, it seems > senseless not to. I have been programming in Forth for several years, and have never seen this programming style before. Since I got my 48 and began reading comp.sys.handhelds, I have noticed this technique (in addition to the frowned upon usage of CLEAR). Are there any compelling reasons for saving and restoring the stack around a program? -- Andrew Scott | mail: andrew@idacom.uucp | - or - ..!uunet!ubc-cs!alberta!idacom!andrew "If you think baseball is exciting, pfft! Forget it!" - Phil Esposito
akcs.falco@hpcvbbs.UUCP (Andrey Dolgachev) (02/02/91)
No there are no real compelling reasons for saving and restoring the stack around a program, the main reason is that it is a workaround around the clear routine in a program. --Falco
akcs.falco@hpcvbbs.UUCP (Andrey Dolgachev) (02/02/91)
Well, there are still problems with it, but it should work for morst programs, at least the ones that do not ask for user input.