: foo ( a b c | e f -- d }
\ *G FOO does something useful

Modern systems, e.g. DocGen and Brad Eckert's DexH extension,
can use this line to produce documentation. We do not
want such systems to have to provide two lines with the
same information

: foo \ a b c -- d
\ *G FOO does something useful
  ( a b c | e f -- d }

Having two definitions of the same thing is a recipe for error.
Enabling the tail after '--' saves keystrokes. Note that '--'
is not mandatory.

Stephen

Similarly, many current systesms, including MPE's, will break
if { ... } is used inside a control structure, e.g.

: foo   \ ...
  ... if
    { a b c -- }
    ...
  else
    ...
  then
;

I propose to add this as an amiguous condition as below.

Ambiguous conditions:
a) The { ... } text extends over more than one line.
b) The expression for local buffer size does not return a single
   cell.
c) { ... } shall not be declared until values previously placed
   on the return stack within the definition have been removed.
d) { ... } is declared within a control structure.

Stephen

Stephen

At least two FSL files use 9 or 10 locals in a couple of words, as I
recall - one of the few non-standard usages that I encountered in the
whole library.  Of course, many of the FSL words are not what I would
call "well-factored" ;-)

It wouldn't break code for the standard to say not to define locals
elsewhere -- code which does that would be just as portable 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 ....  ;

I doubt whether Win32Forth's version conflicts with Marcel's in
its usage.

As other implementations implement locals in memory, their local
variables could leave an address on the stack. Notwithstanding the aim
to  encapsulate existing common practice I think assuming locals will
be implemented in registers is going too far if it means a useful bit
of functionality cannot be included in the standard. After all if local
variables leaving an address on the stack were part of the standard,
compilers that would otherwise allocate them to registers could place
them in memory and the programmer would have to take the performance
hit. Presumably compilers that use registers for locals must have a
mechanism for using memory anyway as they must run out of registers in
some cases.

Anyway if you start calling them local values in your proposal the
problem goes away and everybody is happy.