[441] 2026-07-25 05:13:53 AntonErtl wrote:

comment - What happens when "accept a line" fails

There is a question and discussion about the reference implementation and its behaviour when refill returns 0.

It may be a good idea to make the behaviour in this case explicit in the specification of quit.

[r1706] 2026-07-25 05:04:36 AntonErtl replies:

requestClarification - BYE Semantics Needs Clarification

The specification of quit is the part before the reference implementation. It does not specify what happens if "Accept a line from the input source into the input buffer" fails. The reference implementation chose to perform bye in that case, which is reasonable if there is bye, but that's just a choice of that implementation; note that reference implementations are not normative, and their behaviour in cases that the standard does not specify is therefore not normative, either (and in cases that the standard does specify, the specification is normative, not the reference implementation, if there is any divergence between the two).

Concerning Gforth and SwiftForth, when I do

echo '." foo" cr' |gforth

from a Unix shell, gforth performs bye (and I see it in the definition of (quit), which quit calls through 'quit by default). SwiftForth also returns to the shell, but without printing "foo" (but the crs seem to have an effect).

As for "control is simply returned to the interpreter", that is quit's regular job: Forget the call stack etc., switch input to the user input device, and interpret. The bye part in the reference implementation only comes into play if refill returns 0.

All discussion up to now has been about quit, and maybe the request should have been posted there; I will post a pointer there.

On to bye. If you have no outer level of execution (such as an OS shell), the question is if it makes sense to implement this optional word. But if the users of Z79 find it acceptable to reboot on bye, why not?