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


,------------------------------------------
| 2019-07-16 15:12:55  ruv  wrote:
| comment - Ambiguous condition in case of undefined execution semantics
| see: https://forth-standard.org/standard/core/Tick#contribution-96
`------------------------------------------
1\. By the definition, an execution token identifies some execution semantics.

2\. The specification of this word (i.e. Tick `'`) implies that when a word has execution semantics it shall have the interpretation semantics too, and performing its execution semantics in interpretation state shall be identical to performing its interpretation semantics.

3\. But this specification does not imply the inverse — that if a word has the interpretation semantics it shall have execution semantics too. For example `123` has the interpretation semantics, but it may not have execution semantics. In such case Tick cannot return any meaningful xt for it.

NB: IIRC in some Forth systems Tick and FIND can return meaningful xt for the numbers (but in any case, such Forth system can be easily implemented).

4\. Therefore, an ambiguous condition should exist if `'` is applied to a word with undefined execution semantics (i.e. when the standard does not explicitly specify execution semantics). The examples of such words are: dual-semantics words like `TO`, `S"`, the words with undefined interpretation semantics like `IF`, the numbers.



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


,------------------------------------------
| 2019-07-15 10:33:53  BerndPaysan  replies:
| requestClarification - Ambiguous conditions
| see: https://forth-standard.org/standard/core/TO#reply-260
`------------------------------------------
It all bogs down to how systems implement non-default compilation semantics (NDCS).  Only one (a particular dual-xt approach) can work conforming to the standard.  The TC however decided that the other implementations are ok, considering that there is no standard way to define dual-xt words and that this particular dual-xt approach maybe is not the “right” solution (debate is still open).

Implementations using a `STATE`-smart approach will fail with `POSTPONE` under some conditions (particularly, when you execute that word in interpretation mode, it's no longer performing the compilation semantics).  Implementations using an intelligent `COMPILE,` (like VFX) will fail when you `'` or `[']`, particularly when you `COMPILE,` that result, expecting to append its execution (=interpretation) semantics to the current definition, as specified by `COMPILE,`.

These limitations can probably go away when we find a consensus on how to deal with NDCS words.


,------------------------------------------
| 2019-07-15 17:36:51  AntonErtl  replies:
| requestClarification - Ambiguous conditions
| see: https://forth-standard.org/standard/core/TO#reply-261
`------------------------------------------
As Bernd Paysan writes, one guess is that they did this to allow STATE-smart implementations of TO.  We certainly disallowed ticking it in Forth-2012 for that reason.

However, they did not apply the same restriction to S" (the other dual-semantics word in Forth-94); either they forgot it or that was not the reason why they added that restriction to TO.  Another popular implementation approach for TO is to have it set a variable, and let the value perform either the "TO value" behaviour or just the "value" behaviour.  There are two variations of this: doing that at run time, or at compile time (with IIRC a STATE-smart value).  I currently cannot think of how disallowing POSTPONE TO would help with these kinds of implementations, but maybe there's a better explanation based on that.


,------------------------------------------
| 2019-07-16 17:07:09  ruv  replies:
| comment - Ambiguous condition in case of undefined execution semantics
| see: https://forth-standard.org/standard/core/Tick#reply-262
`------------------------------------------
In the fragment above: "it may not have execution semantics" — I don't sure that the grammatical form choice was suitable. I meant "execution semantics may be absent for it".