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,951 messages   

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

   Message 116,839 of 117,951   
   Ruvim to Anton Ertl   
   Re: value-flavoured structures   
   05 Oct 24 15:06:47   
   
   From: ruvim.pinka@gmail.com   
      
   On 2024-10-04 22:04, Anton Ertl wrote:   
   > Ruvim  writes:   
   >> On 2024-10-04 15:52, Anton Ertl wrote:   
   >>> It can be defined: Gforth has SET-TO   
   > ...   
   >> 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.   
   >   
   > Interesting idea.  Maybe in some future version.   
   >   
   >>> 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*?   
      
   What advantages do you see in *using* the to-based setters?   
      
      
      
      
   >>   
   >> I think, this is because `VALUE` (and co.) is a very old technique that   
   >> is provided out of the box by many systems.   
   >   
   > Yes.  Writing getters and setters is also provided out of the box.   
   >   
   > variable addr-x   
   > : x addr-x @ ;   
   > : set-x addr-x ! ;   
   >   
   > For some reason, people have not written getters and setters.   
      
   The length of the declaration matters. "0 value x" is far shorter than   
   creating two additional colon-definitions.  Thus, this method, which   
   involves *manually* creating of separate colon definitions, is an   
   inconvenient alternative (nevertheless, it is used sometimes).   
      
      
      
   > The lack of flexibility of standard TO has not deterred them from   
   > using that.   
      
   This statement contains the logical fallacy "Survivorship bias" [1].   
      
   There are different use cases. In some use cases the discussed   
   flexibility is not needed, in other — it is needed.   
      
   And you see only examples of using to-based setters when that   
   flexibility is not needed. When it is need, you don't see to-based   
   setters being used — they are not used.   
      
   So your conclusion that the lack of flexibility does not deter the use   
   of to-based setters is wrong.  It does deter that when this flexibility   
   is needed. And when this flexibility is not needed, its lack does not   
   matter at all.   
      
      
   [1]    
      
      
      
   >   
   >> In contrast, to use   
   >> separate getters and setters you need to create your own tool to define   
   >> them.   
   >   
   > Obviously not, see above.   
      
   A tool is needed for convenience. Of course, you always can do manually   
   what the tool does.   
      
   I use such tools to create a store (with setters and getters) not only   
   for single-cell and cell-pair data objects ([2], but also for dynamic   
   character strings (since 2008).   
      
   In classic Forth the latter would look as this:   
      
      \ Declaration (creating)   
      prop( foo ) \ a property, which has the string type   
      
      \ Usage   
      "foo bar " set-foo   
      foo type \ it prints "foo bar "   
      "baz " join-foo   
      foo type \ it prints "foo bar baz "   
      "xxx" set-foo \ store another value   
      
      
   [2] Defining words to create a getter and setter for a slot at once   
      
      
      
   > What tool do you have in mind?   
      
   For example, it could be a defining word "val" that is used as "val x"   
   and creates the getter "x" and the setter "set-x".   
      
   Such a word "val" can be defined like this:   
      
      [undefined] name> [if]   
        : name> ( nt -- xt )   
          name>interpret dup if exit then   
          drop [: -14 throw ;]   
        ;   
      [then]   
      
      : val ( "name" -- )   
        create 0 , [: does> @ ;] execute   
        0. <# latest-name name>string holds s" set-" holds #>   
        ['] : execute-parsing   
        latest-name name> >body lit,   
        postpone ! postpone ;   
      ;   
      
     \ Re "latest-name" see [2]   
      
      \ test   
      t{ val x -> }t   
      t{ x -> 0 }t   
      t{ 3 set-x -> }t   
      t{ x -> 3 }t   
      
      
      \ Let's redefine the setter "set-x"   
      : set-x ( u -- )   
        dup 10 u> abort" too big value for x"   
        set-x   
      ;   
      
      t{ 4 set-x x -> 4 }t   
      t{ 11 ' set-x catch 2drop  x -> 4 }t   
      
      
   Could you show how to implement that in Gforth when the to-based setter   
   "to x" is used?   
      
   NB: the solution must not change the original "x", it must redefine "x".   
   The difference is that the new definition *can* be in a different word   
   list, in which case both definitions (old and new) can be used depending   
   on the context.   
      
      
   [3] Proposal about "latest-name"   
      
      
      
      
      
   >>> 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.   
   >   
   > Does it?  Are they using getters and setters instead?  No.   
      
   How do you know this?   
      
      
   >   
   >> I seen that some implementers provide "value" and "to" only for third   
   >> party programs and don't use them themselves.   
   >   
   > Which ones?  Typing WHERE TO right after startup in Gforth and in   
   > SwiftForth shows a number of uses of TO in both systems.   
      
   I saw this on Reddit, in r/Forth. That was not about any of the five   
   Forth systems you usually test.  I don't have a link to that discussion.   
      
      
      
      
   --   
   Ruvim   
      
   --- 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