Digest #68 2019-07-20
The specification for CATCH states:
"Push an exception frame on the exception stack and then execute the execution token xt (as with EXECUTE) in such a way that control can be transferred to a point just after CATCH if THROW is executed during the execution of xt."
' ' CATCH foo [if] : foo 1234 . ; foo [then] where
foo is undefined. My system displays
1234 (as do GForth,SwiftForth, VFX Forth and Win32 Forth)
The 'undefined word' exception doesn't return to just after
CATCH. This is also true if the word executed by
CATCH parses the rest of the line.
This behaviour seems reasonable to me. Either the specification should be reworded or the above 5 systems are non-compliant. Which is it?
POSTPONE to some words is an ambiguous condition. Actually, it is just a concession to some Forth system implementations (see discussion wrt TO). Since the compilation semantics for these words are well defined, there is no normative cause for an ambiguous condition.
All these five words are "dual-semantics" words (and there are no other such standard words). It is not clear what is the difference that applying
POSTPONE to the last two is not an ambiguous condition. In any case, it seems that in any standard Forth system,
POSTPONE can be correctly implemented for these five words.
If these words are implemented as STATE-smart immediate words then it is enough to put a special flag to them and implement
POSTPONE as the following:
: [ STATE OFF ; IMMEDIATE : ] STATE ON ; : EXECUTE-COMPILING ( i*x xt --j*x ) STATE @ IF EXECUTE EXIT THEN STATE 1+! EXECUTE STATE @ 1 = IF STATE OFF THEN ; : POSTPONE \ ... \ ( xt flags ) DUP MASK-DUALSMART AND IF DROP LIT, ['] EXECUTE-COMPILING COMPILE, EXIT THEN \ ... ; IMMEDIATE
[COMPILE] can be implemented in the similar way too.
Ticking words with undefined interpretation semantics is already ambiguous (4.1.2); same for TO, ACTION-OF and IS.
I think only S" and S" would be affected by the proposed change. These words are implemented as STATE-smart words by some systems, and I think that there is consensus that the standard should not exclude such implementations, so ticking and POSTPONEing should be ambiguous for them, too.
I would like to stress the very different rationales in the cases of Ticking ambiguity and POSTPONEing ambiguity.
The Ticking ambiguity (in the certain cases) is the result of the normative specification text regardless of the particular Forth system implementations.
The POSTPONEing ambiguity (in the certain cases) is just a concession to some Forth system implementations (see the discussion wrt TO). Actually, it is not so difficult to implement
POSPTONE even in some ad-hoc approach for those five special standard words, since the compilation semantics for these words are well defined (see the comment for POSTPONE).