home bbs files messages ]

Forums before death by AOL, social media and spammers... "We can't have nice things"

   comp.lang.forth      Forth programmers eat a lot of Bratwurst      117,927 messages   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]

   Message 116,655 of 117,927   
   Anton Ertl to Ruvim   
   Re: VALUE and TO implementation   
   01 Aug 24 10:07:30   
   
   From: anton@mips.complang.tuwien.ac.at   
      
   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).   
      
   >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.   
      
   >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):   
      
   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]".   
      
   - anton   
   --   
   M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html   
   comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html   
        New standard: https://forth-standard.org/   
      EuroForth 2024: https://euro.theforth.net   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]


(c) 1994,  bbs@darkrealms.ca