Re: "Back & Forth" - Local variables

On 9/01/2025 10:59 pm, albert@spenarnc.xs4all.nl wrote:

In article <9747ef2be5ee93d6a4f0c89352a38cec72624609@i2pn2.org>,
dxf  <dxforth@gmail.com> wrote:

On 9/01/2025 9:50 am, dxf wrote:

On 9/01/2025 5:11 am, Hans Bezemer wrote:

On 08-01-2025 17:27, albert@spenarnc.xs4all.nl wrote:
>
( my CO variant, using the return address)
>
: LOCAL R> SWAP DUP >R @ >R EXECUTE R> R> ! ;
>
VARIABLE A
VARIABLE B
>
\ I'm paranoid :)
>
8 a !
7 b !
>
: divide
    A LOCAL
    B LOCAL
    B ! A !  A @ B @ /
    . CR
;
>
15 3 divide a ? b ?
\ it doesn't mean they're not out to get you
>
Wow! This works! Can't say how solid it is.. but still!

>
Alas not portable.
...

 
Definitely not portable.
 

R EXECUTE doesn't work for ciforth.

There is no guarantee that a saved interpreter pointer on the
stack is an execution token.
 

>
More portable
>
: (lx) >R ;
>
: LOCAL R> SWAP DUP >R @ >R (lx) R> R> ! ;
>
VARIABLE A
VARIABLE B
>
8 A !
7 B !
>
: divide ( a b -- )
   A LOCAL
   B LOCAL
   B ! A !  A @ B @ /
   . CR
;
>
15 3 divide A ? B ?

 
Good catch!
This is an implementation for CO and it works e.g. on ciforth.
But why a different name, CO or ;: as per Chuck Moore.
: CO >R ;
: ;: >R ;
If I use the word (lx) for a decorator, the name makes absolutely no sense.

I didn't realize I was implementing CO.  Now I know what it does.
;: seems a good name.  It was also the name of DOES> predecessor but I could
never find any details.

 
It is less efficient than a machine code implementation, but it doesn't
rely on information on register use in the interpret machine. This
implementation has a good chance to work an a majority of implementations.
 
Groetjes Albert