From: anton@mips.complang.tuwien.ac.at   
      
   Ruvim  writes:   
   >1. From the lexical point of view, "to foo" and "set-foo" are almost the   
   >same.  "to foo" can even be considered a separate fancy word with a   
   >space in its name.   
      
   Even closer: With the to-recognizer you can write ->FOO.   
      
   >3. "set-foo" can be easily redefined (for example, if you want to check   
   >the assigned value to prevent some bugs in advance).   
   >"to foo" *cannot* be redefined. Although, one can redefine "to" to check   
   >its argument and have a special action when its argument is "foo" — this   
   >is very cumbersome.   
      
   Wrong.  It can be defined: Gforth has SET-TO   
      
   which allows you to define what TO FOO does.   
      
   If you mean that a standard program cannot define it, true, but that's   
   just a matter of what is currently standardized.   
      
   >4. "set-foo" can be accessed using qualified names, such as   
   >mymodule::set-foo  or  mymodule( set-foo )   
   >A variant like "to mymodule::foo" could work,   
   >a variant like "to mymodule( set-foo )" cannot work.   
      
   Let's see:   
      
   [~/gforth:152808] gforth   
   Gforth 0.7.9_20241003   
   Authors: Anton Ertl, Bernd Paysan, Jens Wilke et al., for more type `authors'   
   Copyright © 2024 Free Software Foundation, Inc.   
   License GPLv3+: GNU GPL version 3 or later    
   Gforth comes with ABSOLUTELY NO WARRANTY; for details type `license'   
   Type `help' for basic help   
   vocabulary voc  ok   
   also voc definitions  ok   
   5 value val  ok   
   previous  ok   
   voc:val  ok 1   
   . 5  ok   
   7 to voc:val  \ <----------  ok   
   also voc  ok   
   val . 7  ok   
   previous  ok   
   8 ->voc:val  \ <-----------  ok   
   voc:val . 8  ok   
   3 +>voc:val  \ <-----------  ok   
   voc:val . 11  ok   
      
      
   I pointed out exactly where TO VOC:VAL, ->VOC:VAL and +>VOC:VAL occur.   
   No not only can it work, it already works in Gforth.  And here the   
   "standard program excuse" does not apply, because neither your   
   qualification syntax nor Gforth's scope-recognizer are standardized.   
      
   >Bottom line: I don't see any advantages in *using* a to-based setter   
   >over a separate setter.   
      
   However, lots of Forth programmers have defined VALUEs, and barely any   
   have defined getters and setters.  The discussions have been aboyt   
   values vs. variables, not about values vs. getters and setters.   
      
   - 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)