From: dxforth@gmail.com   
      
   On 30/03/2025 11:01 pm, albert@spenarnc.xs4all.nl wrote:   
   > In article <4b84665e38d5a523efc2479f48338ed55d142185@i2pn2.org>,   
   > dxf   wrote:   
   >> On 28/03/2025 8:38 pm, albert@spenarnc.xs4all.nl wrote:   
   >>> In article <19029ff0c8e7cf53335fe62639308e7f92d10240@i2pn2.org>,   
   >>> dxf   wrote:   
   >>>> On 27/03/2025 11:02 pm, albert@spenarnc.xs4all.nl wrote:   
   >>>>> In article <87semzmwok.fsf@nightsong.com>,   
   >>>>> Paul Rubin   wrote:   
   >>>>>> albert@spenarnc.xs4all.nl writes:   
   >>>>>>> In hindsight my locals definition is not convincing, because carnal   
   >>>>>>> knowledge about the behaviour of the return stack is required.   
   >>>>>>   
   >>>>>> It's ok if it's for a specific implementation.  But what I'm having   
   >>>>>> trouble seeing is how the locals get popped in case of an exception.   
   >>>>>   
   >>>>>   
   >>>>> I showed it as an example of the pretty convincing usefulness   
   >>>>> of CO. For this the example had to have to be portable.   
   >>>>>   
   >>>>> A simpler example would be   
   >>>>> \ Temporary set  some-rounding-mode  for the duration of this word.   
   >>>>> : rounding set-rounding-mode CO truncate-mode set-rounding-mode ;   
   >>>>> ...   
   >>>>   
   >>>> Actually it was that example which caused me to *not* go ahead   
   >>>> and implement ;: in the kernel despite a cost of only one header.   
   >>>> How many calls to 'rounding' will you encounter in an application?   
   >>>   
   >>> `rounding: is an internal word in the fp package and it is used 4   
   >>> times.   
   >>>   
   >>>> My guess is one.  The usual example is HEX: but I already had (H.N)   
   >>>> that's more flexible.  For me at least locals was more credible but   
   >>>> again it fell into a range.  For a single use I'd do it manually;   
   >>>> for extensive use (where exceptions etc are likely) a proper locals   
   >>>> may be the only option.  OTOH such decision-making is exactly what   
   >>>> Forth has always been about.   
   >>>>   
   >>>>   
   >>>   
   >>> You can't argue with   
   >>>     :NONAME ." Before " .S CO ." After " .S ;   
   >>>     ' proc_contains_Heisenbug decorated   
   >>>   
   >>> Study python for the concept of decoration.   
   >>> This alone makes CO a worthwhile addition.   
   >>>   
   >>> I have (D.H) that uses CO. Undoubtedly your (H.N) is more complicated.   
   >>   
   >> Possibly though much of the complication lies in what it needs to do - as   
   >> opposed to radix save/restore.   
   >>   
   >> \ Convert unsigned number u to a hexadecimal string c-addr2 u2 in the   
   >> \ HOLD buffer beginning with the least-significant digits.  Exactly   
   >> \ +n hexadecimal characters are returned with any unused positions   
   >> \ being filled with character '0'.  BASE is preserved.   
   >> : (H.N) ( u +n -- c-addr2 u2 )   
   >>  base @ >r hex <# 0 tuck ?do # loop #> r> base ! ;   
   >   
   > Same idea.   
   > ( Generate string with hex format of DOUBLE of LEN digits)   
   >  : 4?  1+ 4 MOD 0= IF &, HOLD THEN ;   
   >  : (DH.) HEX: <# 1- 0 ?DO # I 4? LOOP # #> ;   
   >   
   > ( Derive B. H. DH. from them)   
   >   
   > Only HEX: DEC: is made a separate facility:   
   > : HEX:    R> BASE @ >R  >R HEX CO R> BASE ! ;   
   > : DEC:    R> BASE @ >R  >R DECIMAL CO R> BASE ! ;   
   > To live on and fight another day, e.g. in formatting, or in at-xy that   
   > outputs a position in decimal.   
      
   The question then is can HEX: DEC: be justified.  While you might because   
   CO exists, I'm not sure I could.   
      
   --- SoupGate-DOS v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)