,---------------.
| Contributions |
`---------------´


,------------------------------------------
| 2023-12-25 12:05:23  lmr  wrote:
| example - WORDLIST interaction
| see: https://forth-standard.org/standard/core/MARKER#contribution-325
`------------------------------------------
Is `MARKER` supposed/allowed to also erase subsequent `WORDLIST`-created wid's? If so, after `MARKER` deletes a wid, can/must subsequent invocations of `WORDLIST` re-use that wid (and thereby stay within the system wordlist limit)?


,---------.
| Replies |
`---------´


,------------------------------------------
| 2023-12-25 08:30:25  AntonErtl  replies:
| requestClarification - control stack clearing?
| see: https://forth-standard.org/standard/core/QUIT#reply-1152
`------------------------------------------
THROW and ABORT only clear the data stack if there is no exception frame on the exception stack.

Section "3.1.5.1 System-compilation types" says:

> These data types denote zero or more items on the control-flow stack (see 3.2.3.2). The possible presence of such items on the data stack means that any items already there shall be unavailable to a program until the control-flow-stack items are consumed.

And the programmer also has to ensure that no data stack items are left on the data stack above a control-flow stack item when the program tries to access the control-flow stack item.  Maybe that should be added to the standard.

These restrictions are valid in any state.


,------------------------------------------
| 2023-12-25 11:07:24  lmr  replies:
| requestClarification - control stack clearing?
| see: https://forth-standard.org/standard/core/QUIT#reply-1153
`------------------------------------------
> THROW and ABORT only clear the data stack if there is no exception frame on the exception stack.

an "exception frame" only appears due to `CATCH`, right? Now I'm confused:

* in GForth and others, if a no-good user program calls undefined words, *or* if they call `THROW` / `ABORT` explicitly, then I don't see any of their junk with `.S` when `QUIT` returns to refill user input. The data stack is cleared after (un-handled?) exceptions.
* on the other hand, the suggested reference implementations above *do* use `CATCH`. So, when is the data stack cleared after a program throws (explicitly or via an error)?

> Section "3.1.5.1 System-compilation types" says [...] The possible presence of such items on the data stack means that any items already there shall be unavailable to a program until the control-flow-stack items are consumed
> ... no data stack items are left on the data stack above a control-flow stack item ... 

3.1.5.1 only talks about `X-sys` structures, but `THEN` `REPEAT` etc specs also imply consuming the control stack. OK.

> These restrictions are valid in any state

Hm, are there any primitives that need the control stack available in interpreter `STATE`? What are you alluding to?