Re: VALUE and TO implementation

On 2024-08-03 23:50, minforth wrote:

On Sat, 3 Aug 2024 14:28:46 +0000, Ruvim wrote:

Do not agree?

 I don't, because rejecting Stephen's (and other's) TO-implementation
method just because of some old and unclear wording is against
innovation and optimisation.

What particular is unclear? The wording in the glossary entry for "TO" is quite clear to me: <https://forth-standard.org/standard/core/TO>
Whether "TO" is parsing or non-parsing is nothing to do with optimization.
Moreover, it's easy to implement a parsing "TO" via a non-parsing "TO":
   synonym np-to to  \ it's a non-parsing to
   : to ( interp: x "name" -- ) ( comp: "name" -- )
     '  >r  state @ if  postpone to  r> compile, exit then
     ['] to execute  r> execute
   ; immediate
   \ This does not work in VfxForth because "postpone" and/or "compile,"
   \ are broken for some arguments in VfxForth.
NB: we cannot appeal to the corresponding ambiguous condition in Forth-2012, because "postpone to" can be replaced with:
   [ s" to" forth-wordlist find-name-in name>compile swap lit, compile, ]
and "['] to" can be replaced with:
   [ s" to" forth-wordlist find-name-in name>interpret lit, ]
where
   : lit, ( x -- ) postpone literal ;
   : find-name-in ( sd.name wid -- nt|0 )
     >r 0 [: ( sd.name 0 nt -- sd.name 0 nt | sd.name nt 0 )
       2over 2 pick name>string compare 0= if swap then
     ;] r> traverse-wordlist nip nip
   ;
If you want to allow a non-parsing "TO" in a standard Forth system, you might want to make a proposal.  But it's complicated, and it does not make much sense, because a non-parsing "TO" has *no* advantage over a parsing "TO".
However, as I showed earlier, a parsing "TO" has several advantages over a non-parsing "TO".

 From a higher perspective: Forth has not really innovated over the
last 50 years. Forth-94 achieved streamlining Forth-79 and Forth-83.
Since then: only minor fixes.

Who needs innovations in Forth?

IIRC Charles Moore did not like the standard because it fossilised
history and stifled creativity.

Charles Moore was consistent — he did not care whether the standard rejects any implementation or behavior variation.
If one cares — they should convince other why this variation matters.

Factor and 8th went their own ways, incorporation modern programming
language features.
 Of course, a standard is no place for innovation or new features.

A non-parsing "TO" is not an innovation.

But dogmatic paper lawyering is like digging Forth's grave a little
deeper.

My position concerning "TO" is not dogmatical, but practical :)
--
Ruvim