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


,------------------------------------------
| 2026-07-16 16:01:41  ruv  wrote:
| referenceImplementation - Fix FVALUE reference implementation 
| see: https://forth-standard.org/standard/float/FVALUE#contribution-436
`------------------------------------------
Since `TO` must parse the parse area, we should update the reference implementation in [E.12.6.2.1628](https://forth-standard.org/standard/implement#imp:floating:FVALUE). The minimal change is as follows.

```forth
VARIABLE %var

: TO   \ (  ... "<spaces>name" -- )
  '  [: 1 %var ! ;]
  STATE @ IF COMPILE, COMPILE, ELSE EXECUTE EXECUTE THEN
; IMMEDIATE

: FVALUE ( F: r -- ) ( "<spaces>name" -- )
   CREATE F,
   DOES> %var @ IF F! ELSE F@ THEN
         0 %var ! ;

: VALUE ( x "<spaces>name" -- )
   CREATE ,
   DOES> %var @ IF ! ELSE @ THEN
         0 %var ! ;
```

See also a testcase for `TO` in [contribution-360](https://forth-standard.org/standard/core/TO#contribution-360).



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


,------------------------------------------
| 2026-07-15 05:32:41  AntonErtl  replies:
| requestClarification - The data type of `rec-name` output is too wide
| see: https://forth-standard.org/proposals/recognizer-committee-proposal-2025-09-11#reply-1687
`------------------------------------------
Taking your example fragment, the stack effect says that the result is a translation, and the prose says that its translation token is `translate-name`.  And if you look at the specification of `translate-name`, its prose says:

> Stack effect to produce a translation: ( nt -- translation )

And the stack effect of `translate-name` is ( -- translate-name ).  This means that a translation with the translation token translate-name consists of the stack items ( nt translate-name ).


,------------------------------------------
| 2026-07-16 11:52:07  ruv  replies:
| requestClarification - The data type of `rec-name` output is too wide
| see: https://forth-standard.org/proposals/recognizer-committee-proposal-2025-09-11#reply-1688
`------------------------------------------
> This means that a translation with the translation token translate-name consists of the stack items `( nt translate-name )`.

Agreed. But it's too obscure and unclear. "translation [...] has the translation token translate-name" — "translate-name" is not a translation token, but a word that returns a translation token. Then, looking at the `translate-name` semantic description,  the phrase "stack effect to produce a translation" does not seem like a normative text, too.

One way to make this more clear and normative is to use _intersection_ of arrow types (stack effects).

If we use the symbol «`^^`»  to denote the intersection operator on arrow types:
- `translate-name` Execution: `( -- translation-token  ^^  nt -- translation )`

Thus, it is possible to do without introducing **subtypes** of _translation-token_, but these subtypes are needed in practice (in stack diagrams of real programs), and they make things more clear. The symbols for these subtypes can be derived from the symbol "translation-token", e.g.  "translation-token-nt", "translation-token-cell", "translation-token-float", but that's too long. I would suggest to use a short prefix, e.g. "tt-" or "td-" for these data type symbols.