Re: unexpected behavior of ACCEPT

In a message dated 5/2/2005 2:37:03 P.M. Mountain Standard Time,
kbutterfield_at_lanl.gov writes:

: q1 1000 ms key? key emit ;

: q2 10000 ms key? if pad 10 accept pad swap dump then ;

q1 (immediatly type 1) returns 1
q2 (immediately type 1234) returns 234
q2 (wait 20 seconds type 1234) returns 1234

Where does the leading character go?

Ken B

Very interesting. Here is what I got.using win32forth
the 0 left on the stack came from somewhere ... I suspect I stopped typing
when key? accepted the first key
q2 1234
5652 31 32 33 34 1234 ok

This was most interesting without waiting for the time delay. Nothing
appeared until the time delay was over. Then the hex representation of the numbers
appeared and the cursor sat behind the numbers. I pressed return and '1234'
appeared at the end of the line. I recognized the other numbers as the address
for pad. I 'typed' the contents of pad and as expected found 1234 as below.
5652 4 type 1234 ok
I didn't do the third part because I knew it would be accepted as a numeric
input. It doesn't go to pad because 'if' sees false.

Charlie

----------------------------------------------------------------------
sftalk_at_forth.com The SwiftForth programming discussion email list
To unsubscribe, send subject "unsubscribe" to sftalk-request_at_forth.com
For list command help, send subject "help" to sftalk-request_at_forth.com
Message archives are located at http://www.forth.com/archive/sftalk
----------------------------------------------------------------------
This list is a forum for SwiftForth users. For product support and bug
reports, please send email to support_at_forth.com
----------------------------------------------------------------------
Received on Wed May 04 2005 - 14:44:39 PDT