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


,------------------------------------------
| 2019-07-19 14:52:07  GerryJackson  wrote:
| requestClarification - The specification of CATCH 
| see: https://forth-standard.org/standard/exception/CATCH#contribution-97
`------------------------------------------
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?  


,------------------------------------------
| 2019-07-19 15:08:09  ruv  wrote:
| comment - Ambiguous condition could be removed
| see: https://forth-standard.org/standard/core/POSTPONE#contribution-98
`------------------------------------------
Applying `POSTPONE` to some words is an ambiguous condition. Actually, it is just a concession to some Forth system implementations (see [discussion wrt TO](https://forth-standard.org/standard/core/TO#contribution-95)). Since the compilation semantics for these words are well defined, there is no normative cause for an ambiguous condition.

These words are: [TO](https://forth-standard.org/standard/core/TO), [IS](https://forth-standard.org/standard/core/IS), [ACTION-OF](https://forth-standard.org/standard/core/ACTION-OF).

Another two words are: [S"](https://forth-standard.org/standard/file/Sq) and [S\"](https://forth-standard.org/standard/file/Seq) (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.



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


,------------------------------------------
| 2019-07-18 16:30:50  AntonErtl  replies:
| comment - Ambiguous condition in case of undefined execution semantics
| see: https://forth-standard.org/standard/core/Tick#reply-263
`------------------------------------------
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.


,------------------------------------------
| 2019-07-19 15:15:22  ruv  replies:
| comment - Ambiguous condition in case of undefined execution semantics
| see: https://forth-standard.org/standard/core/Tick#reply-264
`------------------------------------------
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](https://forth-standard.org/standard/core/TO#contribution-95)). 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](https://forth-standard.org/standard/core/POSTPONE#contribution-98)).