Strange "invalid memory address" error with [else] about gforth HOT 4 CLOSED

[ELSE] pushes the current parser hook onto the stack, and replaces it with a parser hook that looks for [THEN] (and similar words). [THEN] pops that hook from the stack.

Since your execute-name? returns true, that true is consumed by [THEN], as parser hook. Of course, calling that hook then will fail.

from gforth.

I see. And is it a bug or not? Either my code or Gforth code does not conform to the standard, or another case also exists. (?)

Obviously, the general solution is to use the separate control flow stack.

[UPD]
By the standard, [IF] and [ELSE] shall be the parsing words. It means that when [ELSE] has executed, the parse area should contain the fragment after the corresponding [THEN]. In Gforth it is not held.

So, the separate control flow stack will not solve this nonconformance. In the approach when the current parser hook is changed, — the nesting call of the outer interpreter loop is needed.

from gforth.

Yes, that sounds reasonable, so I change Gforth's behavior to scan actively.

from gforth.

Just a reference to the corresponding commit: 5b78724

from gforth.