[97] 2019-07-19 14:52:07 GerryJackson wrote:

requestClarification - The specification of CATCH

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."

Given: ' ' 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?

[98] 2019-07-19 15:08:09 ruv wrote:

comment - Ambiguous condition could be removed

Applying 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.

These words are: TO, IS, ACTION-OF.

Another two words are: S" and S" (the variants from FILE word set).

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

The [COMPILE] can be implemented in the similar way too.

[r263] 2019-07-18 16:30:50 AntonErtl replies:

comment - Ambiguous condition in case of undefined execution semantics

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.

[r264] 2019-07-19 15:15:22 ruv replies:

comment - Ambiguous condition in case of undefined execution semantics

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