[436] 2026-07-16 16:01:41 ruv wrote:

referenceImplementation - Fix FVALUE reference implementation

Since TO must parse the parse area, we should update the reference implementation in E.12.6.2.1628. The minimal change is as follows.

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.

[r1687] 2026-07-15 05:32:41 AntonErtl replies:

requestClarification - The data type of `rec-name` output is too wide

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

[r1688] 2026-07-16 11:52:07 ruv replies:

requestClarification - The data type of `rec-name` output is too wide

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.