Re: RfD - Enhanced local variable syntax (long)

Alex McDonald wrote:
> Stephen Pelc wrote:
> > At long last I've started on my Forth200x tasks. Here's the first
> > cut of the enhanced local variables using the { ... } notation.
>
> Coincidentally, I have been working on the locals implementation in the
> W32F native code version this last week. Timely; thank you.
>
> >
> > Stephen
> >
> > RfD - Enhanced local variable syntax
> > ====================================
> > Stephen Pelc - 20 August 2006
> >
> > Problem
> > =======
> > 1) The current LOCALS| ... | notation explicitly forces all locals
> > to be initialised from the data stack.
> > 2) 1) The current LOCALS| ... | notation defines locals in reverse
> > order to the normal stack notation.
> > 3) When programming large applications, especially those interfacing
> > with a host operating system, there is a frequent need for tem****ary
> > buffers.
> > 4) Current implementations show that creation and destruction of
> > local buffers are much faster than using ALLOCATE (14.6.1.0707)
> > and FREE (14.6.1.1605).
>
> Agree with the above, and would add
>
> 5) Current implementations of { are diverging in the facilities they
> provide.
> 6) { and } are visually confusing. Perhaps select another character or
> string, which would allow existing implementations to do their own
> thing unmolested.

And;

7) LOCALS| has the following restrictions on the use of the rstack;

13.3.3.2 Syntax restrictions
c) Locals shall not be declared until values previously placed on the
return stack within the definition have been removed;
d) After a definition's locals have been declared, a program may place
data on the return stack. However, if this is done, locals shall not be
accessed until those values have been removed from the return stack;

Can this restriction be lifted with { locals? W32F has no such
restriction, although the current implementation is not optimal. W32F
keeps an rstack base pointer at run time as it sup****ts variable length
locals, something that isn't really required and isn't proposed in ths
RfD.

It's only an issue for implementations that use the rstack for locals;
for them, removing this restriction would simply require r> >r 2>r and
2r> to communicate to the locals at compile time what they're doing
with the return stack. 

-- 
Regards
Alex McDonald