Re: test for empty stack

On Wed, 06 Sep 2006 17:52:54 -0500, Virgil wrote:

This is not a test for an empty stack but a test for lack of input.
If one does "" "" INPUT ENTER one gets "" on the stack.

Aha, the "delay line" in my head was still seeing "DEPTH,"
but you did say DUP SIZE (not DEPTH), sorry!

Well, now that my brain is starting to catch up with what you
actually said, isn't a space (or other non-compiling stuff)
returned by INPUT also very similar to "no input"?

If the purpose of INPUT is eventual parsing,
I think that the only way to find out what the string
actually represents is to parse it, then see what one got.

The OP had asked "I am writing a program
which requires one input value.
I wanted to trap the error of no input
in which case I would assign a value."

A later suggestion to use INPUT to ask for a value
brought out my "standard stump speech" about INPUT:

In general, to get "a [unspecified type] value,"
one must parse the string after INPUT,
after which in general you are no better off
than if you just started your program having no idea what,
if anything, was put on the stack,
unless unusual care is taken in parsing.

Oh well, stump speech over -- what was the question? ;-)

Given the Subject: test for empty stack
and:
"I am writing a program which requires one input value.
I wanted to trap the error of no input
in which case I would assign a value."

Gee, I've done that exact thing, many times...
how did it go, then? Oh yes, it was:

DEPTH NOT default.value IFT

Sorry for my not paying attention :)

Lesson plan:
http://www.uoregon.edu/~ftepfer/SchlFacilities/TireSwingTable.html
http://home.insightbb.com/~gregorym/it.jpeg

[r->] [OFF]
.

Relevant Pages

  • test for empty stack
    ... In UserRPL how does one test for an empty stack? ... I am writing a program ... I wanted to trap the error of no input in ...
    (comp.sys.hp48)
  • Re: extract config files tokens: need advice on algorithm
    ... I'd kill comments in the lexer. ... There are plenty of sources on the web for writing lexer and writing ... parsing code written in the normal structured way. ... Since 'named' is quite a common file to parse I expect you will be able ...
    (comp.programming)
  • Re: Where the code trouble is?
    ... but in which writing at would NOT result in a trap, because the architectures happen to have memory at that location. ... Although *NULL might well not trap, it's in general more likely to, which can help with debugging. ... IMHO the first stage in trying to debug a problem is always to reproduce ...
    (comp.lang.c)
  • Re: Where the code trouble is?
    ... The vast majority of machines in use have NULL as a trap location. ... trap, it's in general more likely to, which can help with debugging. ... I would also say that even on systems where writing to *NULL does not trap, it is still likely to give reproduceable results which can be debugged. ... IMHO the first stage in trying to debug a problem is always to reproduce it, since if you can't reliably reproduce it you will never know if you have fixed what caused the original bug report or something else that you think might have caused it but did not. ...
    (comp.lang.c)
  • weird math
    ... I am writing a program to parse a CSV file downloaded from my bank. ... keep a running balance, but I'm getting a weird total. ...
    (perl.beginners)