6.1.0695 ACCEPT CORE

ACCEPT typically uses KEY (or EKEY) and thus should get the input from the same source as KEY. On a hosted console Forth, that's usually STDIN, but if you run the Forth in a GUI windows, it's the keyboard input events from that window.

Forth does not know about STDIN. Many Forths, both desktop and embedded, allow I/O through KEY and EMIT and friends to be vectored. This could be through a console, a serial line, a TCP/IP connection. How the vectoring occurs is not (yet) standardised. ACCEPT works with KEY and EMIT and friends and so inherits whatever vectoring the Forth system provides. Note that the current input and output device should be vectored separately.

Stephen

1. The standard document is clear here: What happens to the display upon receiving the line terminator is implementation-defined, but the recommendation (in the rationale) is to leave the cursor at the end of the entered text without echoing the line terminator. Note that if your ACCEPT supports editing with cursor-left and such, you should move the cursor to the end rather than leaving it where it is.

2. That's also clear in the document: When a line terminator is received, nothing is appended to the string. I.e., the terminator should not be placed into the string.

3. The document specifies termination only on receiving the line terminator, and does not specify any particular behaviour when reaching n1 characters. Gforth places the cursor behind the n1th character, but when you enter a character then, it just beeps.

Thanks for the clarifications. I thought that was the case with #1, but now you've made it clear.

About #2, I was not sure if it meant nothing is appended after the terminator, like maybe do not append a 0 (I'm coming from a long history of C programming, so my intuition keeps telling me to think of that there...).

And about #3, yes, the standard didn't tell me what to there...which was a surprise, but I guess there are good reasons for leaving that implementation-dependent. Just so you know, the reason I asked is that the little system I'm developing will be accepting a long string of text copied and pasted into a terminal window, with no editing on the Forth side, and the total amount of text may be longer than what will fit into a local buffer. . So now I know I'm free to handle this situation however I want, which is exactly what I was hoping to hear.

Thanks again!

Described like this (with "cursor", "end-of-line") ACCEPT seems to require a specific input and output behavior. The original specification allows calling some OS function to accept characters (then there is no control over where/if the input appears and in what fashion). Specifying a requirement for both KEY and EMIT to be used helps, but then editing keys and mouse actions are problematic (at least for the system implementor). Maybe these aspects can be clarified.

-marcel

PS: why can't we see the message we're responding to? (a problem with ACCEPT ?-)

The standard is very clear that nothing is appended when the line-terminator is received, not even a NUL character. Also, if n2=n1, there is no room in the buffer for appending anything.

I guess the reason for not specifying anything for 3) is that when dealing with terminals in cooked mode, the system gets control back only after the user has pressed the terminator, and may have typed far beyond n1. If the system uses the terminal in raw mode (i.e., it can handle each character separately), it can provide immediate feedback (like Gforth is doing) when n1 is reached. So the standard did not specify what to do about this case.

I don't think that we should require that KEY and EMIT is used, because KEY does not work properly on terminals in cooked mode; I have seen some Forth systems (among them, SP-Forth) that use cooked mode, and where KEY does not return after one character has been typed.

+n2 means that n2 is non-negative. It may be zero. (+n1, too, but for n1 non-zero-ness is specified in the prose).

Oh, thank. Forget that +n does not mean positive, but non-negative.