From: ruvim.pinka@gmail.com   
      
   On 2024-10-04 15:52, Anton Ertl wrote:   
   > 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.   
      
   Yes, I know ))   
   I wonder why a kind of "TO" is not used to set this field/property, and   
   *maybe* a kind of "ACTION-OF" to get this property.   
      
      
   > If you mean that a standard program cannot define it, true,   
      
   Of course, I mean a standard program (and that is by default).   
   Otherwise my statement would be a denial of the obvious truth ;)   
      
      
   > but that's just a matter of what is currently standardized.   
      
   Yes, this is by default.   
      
      
      
   >> 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,   
      
   By "could work" I mean that this can potentially work in *any* system   
   that have the corresponding capabilities (e.g., the Recognizers API).   
      
      
   >> a variant like "to mymodule( set-foo )" cannot work.   
      
   Typo: this should be read "to mymodule( foo )"   
      
      
   >   
   > 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   
      
   Behaves as expected!   
      
   >   
   > 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.   
      
   Yes, that's right!   
      
      
      
      
   >> 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.   
      
   Do you mean that this is due to some advantages in *using*?   
      
   I think, this is because `VALUE` (and co.) is a very old technique that   
   is provided out of the box by many systems.  In contrast, to use   
   separate getters and setters you need to create your own tool to define   
   them.   
      
      
      
      
   > The discussions have been aboyt   
   > values vs. variables, not about values vs. getters and setters.   
      
   This shows that some people don't like the to-based approach.   
      
   I seen that some implementers provide "value" and "to" only for third   
   party programs and don't use them themselves.   
      
      
   --   
   Ruvim   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)