Re: VALUE and TO implementation

On 2024-08-01 14:07, Anton Ertl wrote:

Ruvim <ruvim.pinka@gmail.com> writes:

On 2024-07-31 21:33, Anton Ertl wrote:

Maybe those who like this kind of
TO implementation will make a proposal that means that you cannot
POSTPONE TO with a user-defined POSTPONE.

>
How?

 That's up to those to work out who would benefit from such a
restriction.

The alternative (which may require less work) is to
implement TO in a way that makes such a restriction unnecessary (i.e.,
such that POSTPONE TO works even with a user-defined and maybe also
the system-defined POSTPONE).

It is better to implement "to" as a parsing word.
Because another disadvantage of a not parsing "to" (beside the problem with "execute-parsing") is that such "to" cannot be used to implement the Forth text interpreter loop itself. Otherwise, "to" will not work when it's encountered by this text interpreter in interpretation state (in some implementations for "to", at least).
A plausible implementation, for example:
   0 0 2value current-lexeme
   : ?found ( 0 -- _ | x -- x )
     dup if exit then
     -13 throw" unrecognized: {current-lexeme}"
     \ NB: string interpolation is employed
   ;
   : translate-lexeme ( i*x sd -- j*x )
     2dup to current-lexeme
     perceive ?found ( ut xt.tt ) execute
   ;
   : interpret
     begin parse-lexeme dup while translate-lexeme repeat 2drop
   ;
   interpret 0 value x  1 to x  x .
   \ if "to" is not a parsing word and implemented
   \ in the approach (2) below,
   \ this line prints 0, but it shall print 1

Disallow obtaining the name token for "to"? That's a very weak
approach.

 That appears to be overly blunt to me and would be unlikely to gain my
support.
 

It seems, it is possible to test whether "to" is parsing, and if not,
redefine it to provide a parsing "to" in a standard system.
>
I came up with the following test:
>
   0 value _v1 immediate
   0 value _v2
>
   : test(to)
     1 1
     [ 1 ] to _v1 _v2 [ ( 1 | 1 0 ) ?dup 2drop ]
     ( 1 | 1 0 ) ?dup 2drop
   ;
   test(to) _v2 [if]
     .( ["to" is not a parsing word] )
   [else]
     .( ["to" is a parsing word] )
   [then]

 This is clever.  Given that your test uses only Forth-94 features,
already Forth-94 can see the difference between parsing and
non-parsing TO.

Then, can we conclude, that "to" *shall* be implemented as a parsing word?
The standard normatively specifies that "to" does parsing.
The rationale says that "Some implementations of TO do not parse", but this is not a normative part. In the normative part an ambiguous condition is declared:
   | An ambiguous condition exists if any of
   | POSTPONE, [COMPILE], ' or ['] are applied to TO.
*** (1)
The intent of this ambiguous condition in Forth-94 was probably to ensure that a standard program will not be able to detect whether "to" does parsing (and thus to allow different implementations).
Now it is obvious that this ambiguous condition does not prevent a standard program to detect whether "to" does parsing. This clearly means that implementations of "to" that do not parse *are not allowed*.
Moreover, in Forth-2012, a standard program can define an equivalent of "postpone" and Tick (both "'" and "[']") and apply them to "to".
Therefore, the ambiguous condition (1) can be removed without any consequences for standard programs and systems.

Suddenly, compilation of "test(to)" failed in VfxForth, version
VFX Forth 64 5.43 [build 0199] 2023-11-09 for Linux x64
>
So, either this "test(to)" or VfxForth is not standard compliant.

 I see nothing here that makes TEST(TO) non-standard.  One can condense
the case where VFX fails into:
 0 value _v1 immediate
: test-to 1 to _v1 ;
 VFX Forth 64 5.43 [build 0199] reacts with:
 Err# -4 ERR: Data stack underflow.
  -> : test-to 1 to _v1 ;
                       ^
 Let's see how your test works for the original flag-setting TO
(without optimizations):
 

*** (2)

variable to-state false to-state !
: to true to-state ! ;
: value
     create ,
   does>
     to-state @ if
       ! false to-state !
     else
       @
     then ;
 Your test indeed outputs "["to" is not a parsing word]".
 

--
Ruvim