[78] 2019-05-19 13:57:46 mcondron wrote:

comment - Behavior when no text found

When no text is found (i.e. CHAR followed by nothing but spaces until the end of the line) should this be an ambiguous condition, or should CHAR place 0 on the stack?

[r206] 2019-05-12 21:04:32 mcondron replies:

requestClarification - Behavior at end of line and end of data

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!

[r207] 2019-05-13 07:04:41 MarcelHendrix replies:

requestClarification - Behavior at end of line and end of data

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 ?-)

[r208] 2019-05-14 09:41:25 AntonErtl replies:

requestClarification - Behavior at end of line and end of data

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.