peraino@gmuvax2.gmu.edu (Bob Peraino) (01/29/91)
All of this talk about using CLEAR in programs got me thinking. I have NEVER used CLEAR in a program. This got me thinking even more, and I am ready to make the following statement, open for discussion: CLEAR will NEVER be needed in a program. I don't want some wise-guy to tell me, "You're right; you could just do DEPTH DROPN" I mean, that general function will never be needed in a program. Which means, the use of CLEAR is extremely sloppy. Throw some "what-ifs" at me, and I'll think about them. peraino@gmuvax.gmu.edu
TNAN0@CCVAX.IASTATE.EDU (01/29/91)
Ok, peraino... WHAT IF: You had a variable number of arguments on the stack (arbitrary number), your program had several error traps to detect things like user-entry-errors, argument-type-errors, etc... and it was imperative that you conserve memory and time. For example, no solution that takes 200 bytes or 5 seconds is worth the declaration "it's well structured..." The HP is a stack based machine... There is NOTHING unclean about using simple stack commands like DEPTH and DROPN to provide a quick efficient solution. However, if your program also DEPOSITS an arbitrary number of results to the stack, the DEPTH DROPN solution may not work... GULP... ---Xeno P.S. I'll believe GOTOs are unnecessary when I see a processor with no JUMP.
akcs.falco@hpcvbbs.UUCP (Andrey Dolgachev) (02/02/91)
O.K., what if you have a program which has many arguments floating around on the stack, and then you have a quit key which stops the program from any point. Now, before you stop the program, you want to clear the stack of all the arguments which are needed anymore. Now, of course, it would be possible and feasible to drop the specific # of objects, dependig on where you stoppped, but it would require additional programming, which depending on the complexity of the program, could be too length. Instead, if you save the stack before the program begins, only a clear would be required, which would be far simpler, easier, faster, etc. Another problem is that if you have a buggy program which accidently takes more for internal arguments than it should, it could end up accidently using up one of the arguaments which were on the stack before the program was executed, instead of just erroring out. Well, just a few ideas, however, I do agree that using CLEAR is extremely ssloppy if it is used with out a valid reason. --Falco
akcs.scotty@hpcvbbs.UUCP (SCOTTY THOMPSON) (02/03/91)
Options? Okay. The only time I used CLEAR in a program is to collect garbage in the display before leaving (I used the PROMPT command, disabled the user keyboard, etc., so the user had only one option to leave, the EXIT key...). Afterwards, I restored the stack previously saved. The moral? Save the stack first, if you have garbage before you leave a program (which you shouldn't, unless you use like PROMPT or somthing), then I don't see any reason not to use CLEAR before restoring the stack...Scotty.