[325] 2023-12-25 12:05:23 lmr wrote:

example - WORDLIST interaction

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

[r1152] 2023-12-25 08:30:25 AntonErtl replies:

requestClarification - control stack clearing?

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.

[r1153] 2023-12-25 11:07:24 lmr replies:

requestClarification - control stack clearing?

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?