From: peter.noreply@tin.it   
      
   On Thu, 3 Jul 2025 20:47:07 +0400   
   Ruvim  wrote:   
      
   > On 2025-07-03 17:11, albert@spenarnc.xs4all.nl wrote:   
   > > In article <1043831$3ggg9$1@dont-email.me>,   
   > > Ruvim   wrote:   
   > >> On 2025-07-02 15:37, albert@spenarnc.xs4all.nl wrote:   
   > >>> In article <1042s2o$3d58h$1@dont-email.me>,   
   > >>> Ruvim   wrote:   
   > >>>> On 2025-06-24 01:03, minforth wrote:   
   > >>>> [...]   
   > >>>>   
   > >>>>> For me, the small syntax extension is a convenience when working   
   > >>>>> with longer definitions. A bit contrived (:= synonym for TO):   
   > >>>>>   
   > >>>>> : SOME-APP { a f: b c | temp == n: flag z: freq }   
   > >>>>> \ inputs: integer a, floats b c   
   > >>>>> \ uninitialized: float temp   
   > >>>>> \ outputs: integer flag, complex freq   
   > >>>>>     <: FUNC < ... calc function ... > ;>   
   > >>>>   
   > >>>> BTW, why do you prefer the special syntax `<: ... ;>`   
   > >>>> over an extension to the existing words `:` and `;`   
   > >>>>   
   > >>>>     : SOME-APP   
   > >>>>        [ : FUNC < ... calc function ... > ; ]   
   > >>>>        < ... >   
   > >>>>     ;   
   > >>>>   
   > >>>> In this approach the word `:` knows that it's a nested   
   > >>>> definition and behaves accordingly.   
   > >>>   
   > >>> Or it has not even know it, if [ is smart enough to compile a   
   > >>> jump to after ].   
   > >>   
   > >> This can be tricky because the following should work:   
   > >>   
   > >>    create foo [ 123 , ] [ 456 ,   
   > >>   
   > >>    : bar  [ ' foo compile, 123 lit, ] ;   
   > >    
   > > If this bothers you, rename it in [[ ]].   
   > >    
   > > Once we enhance [ ] to do things prohibited by the standard,   
   > > (adding nested definitions) I can't be bothered with this too much.   
   >    
   >    
   > The standard does not prohibit a system from supporting nested    
   > definitions in whichever way that does not violate the standard   
   > behavior.   
   >    
   >    
   > Yes, something like "private[ ... ]private" is a possible approach,   
   > and its implementation seems simpler than adding the smarts to `:`   
   > and `;` (and other defining words, if any).   
   >    
   > The advantage of this approach over "<: ... ;>" is that you can   
   > define not only colon-definitions, but also constants, variables,   
   > immediate words, one-time macros, etc.   
   >    
   >    
   >    : foo ( F: r.coefficient -- r.result )   
   >      private[   
   >        variable cnt   
   >        0e fvalue k   
   >        : [x] ... ; immediate   
   >      ]private   
   >      to k   0 cnt !   
   >      ...   
   >    ;   
   >    
   > It's also possible to associated the word list of private words with   
   > the containing word xt for debugging purposes.   
   >    
   >    
   > --   
   > Ruvim   
   >    
      
   In lxf I have module, private, public, end-module   
   your example would be   
      
   module   
   private   
      
   variable cnt   
   0e fvalue k   
   : [x] ... ; immediate   
      
   public   
      
   : foo ( F: r.coefficient -- r.result )   
        to k   0 cnt !   
        ...   
      
      
   end-module   
      
   end-module will remove all headers from the private words in the module   
   I am not found of mixing definitions inside others.   
      
   BR   
   Peter   
        
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)