9.6.1.2275 THROW EXCEPTION

The text starts with

If any bits of n are non-zero,

and later it says

If the top of the stack is non zero [...]

Admittedly it does not say anything about what happens if n=0, but that generally means that it does nothing. However, what it does in that case is to pop n; this is reflected in the stack effect ( k * x n -- k * x ) for that case, but the specification does not say that this stack effect refers to this case, so I have proposed to make it clear that n is popped.

I didn't implement my DO/LOOP to store limits/counters on the return stack

In the case of your do-loop, a system-specific solution is to keep in the exception frame the pointer of the loop control stack (or the number of loop control parameters that are updated by do-loop run-time), and restore the pointer (or unloop the parameters) in THROW.

Certainly, any similar user-made constructs have identical issues [...] How else would user code that acquires global resources properly interoperate in the presence of THROW?

A proper way for programs to free resources is to use CATCH (see an example in A.9.6.1.2275).

Actually, even your do-loop can be implemented in a portable way using quotations:

: do c{ [: do }c ; immediate
: ?do c{ [: ?do }c ; immediate
variable no-exit \ it should be a user variable in case of multitasking
: execute-loop-safely ( xt -- flag-to-exit ) catch no-exit @ no-exit off swap dup if (unloop) then throw 0= ;
: (finalize-loop) c{ no-exit on ;] execute-loop-safely if exit then }c ; immediate
: loop c{ loop (finalize-loop) }c ; immediate
: +loop c{ +loop (finalize-loop) }c ; immediate

Here I use c{ ... }c notation (construct) to compile code fragments, and in this case it's equal to ]] ... [[ notation, that is to apply postpone to each contained word.

The variable no-exit is used to properly handle unloop exit phrase. So, a word

  : test 10 0 do i .  i 4 > if unloop exit then  loop ."  fail " ;

is compiled as

  : test 10 0 [: _do i .  i 4 > if unloop exit then  _loop  no-exit on ;] execute-loop-safely if exit then ."  fail " ;

Where _do and _loop are the original versions of these words.

That's quite an interesting technique. Also, I've noticed I was mostly wrong about most of my concerns.

Is there a place, online, to discuss many Forth-related things without distracting the spec. experts with my amateurish ramblings?

Is there a place, online, to discuss many Forth-related things

1. ForthHub on GitHub platform:

2. Discussions in the dedicated discussion repository

3. Discussions in the issues of the in the dedicated discussion repository

4. Discussions in the forthhub team

5. Forth related questions at StackOverflow

6. Forth subreddit at Reedit

7. The old comp.lang.forth news group, that is available via NNTP and Google Groups web-interface.

8. Various forums, chats in IRC, Telegram etc.

Is there a place, online, to discuss many Forth-related things

The most active places I've found seem to be the Facebook groups: ForthArduino Early Forth Forth Programming Forth 2020

The committee endorses ruv's answer. closed.

See also some thoughts on this subject in the comment in 2019 by Anton.

In the long run we should probably specify a (logical) input stack that physically typically (or requiredly?) resides on the return stack, and that THROW restores, like the other stacks, with appropriate changes in words like INCLUDE-FILE, EVALUATE, and LOAD. The restoration of course has to restore the input source in the same way as regularly leaving INCLUDE-FILE, EVALUATE, and LOAD would. But if the code controlled by catch just advances the position in the current input stream, no input stack item is pushed and throw does not restore it, and therefore does not restore the position.

I leave this open so we don't forget about wanting to do this change.

As I can see, "nesting of input sources (i.e., with LOAD, EVALUATE, or INCLUDE-FILE)" is mentioned, and un-nesting input source specifications is required by the section 9.3.5 Exception handling.

And A.13 also says that the standard "does require INCLUDE-FILE to unnest the input source specification if an exception is THROWn".

I used to think that it's an omission that THROW restores the input source specification, while CATCH does not save it. But actually it's by intention. The Idea is that THROW restores what INCLUDE-FILE (or EVALUATE, etc) saves. If nothing was saved (between an instance of THROW and the nearest instance of CATCH), then the input source specification is already the same as before CATCH, and no need to restore it.

In the long run we should probably specify a (logical) input stack

It's a possible way to describe this behavior more clear/ thoroughly. Another possible way is to formally use the exception stack (and exception frames) for that, taking into account that the Exception word set is mandatory.

Although, it seems this formalism is not worth introducing, since there is no questions on this regard. The questions were only about the state of the input source (whether this state shall be restored or not). So it's enough to clarify only this.

If the top of the stack is -2 , and there is no handler, then THROW is supposed to display a message.
I can't see how the reference implementation does that.

A reference implementation is just an example, it is not required to cover all the cases.

The reference implementation for THROW is preceded by the note: "This is the counter part to E.9.6.1.0875 CATCH", if we follow the link, we in turn can read in the note: "This sample implementation does not explicitly handle the case in which CATCH has never been called (i.e., the ABORT behavior)".

So, the implementation explicitly says that the case of no handler is not covered.