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


,------------------------------------------
| 2022-06-23 21:59:20  poggingfish  wrote:
| referenceImplementation - 
| see: https://forth-standard.org/standard/core/ROT#contribution-241
`------------------------------------------
```
: ROT >R swap R> swap ; 
```


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


,------------------------------------------
| 2022-06-22 16:47:31  AntonErtl  replies:
| referenceImplementation - 
| see: https://forth-standard.org/standard/core/RFetch#reply-828
`------------------------------------------
Concerning

    : r@ postpone r> postpone dup postpone >r ; immediate

This definition has other than default compilation semantics, while the standard `r@` has default compilation semantics.  This makes a difference for `[compile]`.


,------------------------------------------
| 2022-06-22 22:24:19  ruv  replies:
| referenceImplementation - 
| see: https://forth-standard.org/standard/core/RFetch#reply-829
`------------------------------------------
> This definition has other than default compilation semantics,

Now I can't agree on that, since a program cannot detect other than default compilation semantics for this `r@`.

If the compilation semantics for a word are to appends its execution semantics — then these compilation semantics are equivalent to a default (see [3.4.3.3 Compilation semantics](https://forth-standard.org/standard/usage#usage:compile)), i.e. they cannot be operationally distinguishable.

A program can test that the compilation semantics for this `r@` are to append the execution semantics that are specified in the glossary entry.

In the same time, a program don't have other way to test the execution semantics for `r@`, since a system is allowed to not provide an execution token that identifies the execution semantics for `r@` at all, since interpretation semantics for `r@` are undefined by the standard. In other words, no _xt_ may be considered as an identifier of the execution semantics for `r@` that are specified in the glossary entry.



>  This makes a difference for `[compile]`.

Yes, we [discussed](https://forth-standard.org/standard/core/BracketCOMPILE#reply-670) that.
It's a built-in problem of the word `[compile]` by design. And it's one of reasons why this word will be removed from the standard (destandardized).

-----

BTW, my test case contains several shortcomings: 
  1. Tick can be applied to the name `r@` only if `find` in interpretation state and in compilation state returns the same values for this name (so it should be checked before use Tick in this case).
  2. Instead of Tick, the result of `find` in compilation state can be used (and than no need for the double check).
  3. `word` returns a counted string in a [transient buffer](https://forth-standard.org/standard/usage#usage:transient) that may be invalid after parsing next lexeme.

A better variant:

```
: execute >r r@ execute r> drop ;

: []compile' ( t "ccc" -- t )
  state @ 0= -14 and throw
  bl word find dup 0= -13 and throw 1 =
  if execute else postpone literal postpone execute then
; immediate

t{ :noname 123 >r []compile' r@  r> drop ; execute -> 123 }t
```



,------------------------------------------
| 2022-06-23 07:18:44  ruv  replies:
| referenceImplementation - 
| see: https://forth-standard.org/standard/core/RFetch#reply-830
`------------------------------------------
>> ```
>> : r@ postpone r> postpone dup postpone >r ; immediate
>> ```
>> This definition has other than default compilation semantics,

> a program cannot detect other than default compilation semantics for this `r@`.

On the other hand, in some cases a program can conclude that this word is an immediate word: if [`find`](https://forth-standard.org/proposals/clarify-find-more-classic-approach?hideDiff#reply-682) returns the same `( xt 1 )` independently on STATE, then the word is immediate (but the converse does not hold). By that, the program has actually obtained an xt for `r@`, but this xt doesn't identify the execution semantics specified in the glossary entry, and this is allowed (due to the corresponding condition in [4.1.2 Ambiguous conditions](https://forth-standard.org/standard/doc#doc:ambiguous)).

So under the hood this `r@` can be treated a as a word having other than default compilation semantics, but as a black box, this implementation meets the specification.

-----

If `r@` is implemented as an ordinary word, a program can also obtain the xt of this word during text interpreting. But, to perform the compilation semantics for `r@`, in this case the program **should rely** that this xt identifies the execution semantics specified in the glossary entry. And this approach doesn't work in edge cases.