[comp.sys.handhelds] Using CLEAR in a program

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.