From: ruvim.pinka@gmail.com   
      
   On 2024-08-01 14:07, Anton Ertl wrote:   
   > Ruvim  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   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)