Re: RfD - Enhanced local variable syntax (long)

Alex McDonald wrote:
> Andreas Kochenburger wrote:

> > I'd prefer that the locals definition must be the first definition
> > within a word, i.e. appear right after : NAME ..
> > This can easily be checked by the compiler.

> It can't be parsed for as it would break a lot of code. It can be
> detected only if { can ascertain that there's been no code generated
> between : and { . Would that not give optimising compilers some
> difficulties?

If you want to check for that, you could have { be something that :
:NONAME and DOES> check. Any other time it doesn't work or gives an
error message.

It wouldn't break code for the standard to say not to define locals
elsewhere -- code which does that would be just as ****table as it is
now. Any implementator who wants to let people define locals elsewhere
could do so. The question is whether it would  be good to require
implementors to allow locals definition elsewhere. And if so, which
places should locals definition be allowed?

Good optimising compilers will put locals in available registers and
will only move them out of the registers when the registers must be
used for something else -- for example a called word that uses locals,
or a word in another task that uses locals.

But less-optimised Forths will tend to put locals on the return stack,
and if they do there's a question what other return-stack uses might
interfere with locals or vice versa. What I remember for that is direct
use of the return stack ( >R etc), loops, and calls. Calls are no
problem, you won't use your locals inside a word you call and the
return stack will be clean when that word returns.

Implementations that call a deeper routine when they switch to compile
state are already nonstandard so that shouldn't be a problem.

: ]FOO      .... local1 ] local2 ....  ;

: TEST [ do-something ]FOO ;  ought to work just fine.