Re: Locals revisited

On 30/03/2025 11:01 pm, albert@spenarnc.xs4all.nl wrote:

In article <4b84665e38d5a523efc2479f48338ed55d142185@i2pn2.org>,
dxf  <dxforth@gmail.com> wrote:

On 28/03/2025 8:38 pm, albert@spenarnc.xs4all.nl wrote:

In article <19029ff0c8e7cf53335fe62639308e7f92d10240@i2pn2.org>,
dxf  <dxforth@gmail.com> wrote:

On 27/03/2025 11:02 pm, albert@spenarnc.xs4all.nl wrote:

In article <87semzmwok.fsf@nightsong.com>,
Paul Rubin  <no.email@nospam.invalid> 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.