15.6.2.0830 BYE TOOLS EXT

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?

The 'BYE' specifications says 'Return control to the host operating system, if any.' That's not what I'm seeing IRL. A more proper wording might be "Return control to the interpreter;"

"Return control to the interpreter" is the behavior of QUIT. I've never encountered a Forth system running under an OS where BYE didn't terminate the Forth process.