Next: ANS Forth locals, Previous: Locals, Up: Locals
{ local1 local2 ... -- comment }
or
{ local1 local2 ... }
E.g.,
: max { n1 n2 -- n3 } n1 n2 > if n1 else n2 endif ;
The similarity of locals definitions with stack comments is intended. A
locals definition often replaces the stack comment of a word. The order
of the locals corresponds to the order in a stack comment and everything
after the --
is really a comment.
This similarity has one disadvantage: It is too easy to confuse locals declarations with stack comments, causing bugs and making them hard to find. However, this problem can be avoided by appropriate coding conventions: Do not use both notations in the same program. If you do, they should be distinguished using additional means, e.g. by position.
The name of the local may be preceded by a type specifier, e.g.,
F:
for a floating point value:
: CX* { F: Ar F: Ai F: Br F: Bi -- Cr Ci } \ complex multiplication Ar Br f* Ai Bi f* f- Ar Bi f* Ai Br f* f+ ;
Gforth currently supports cells (W:
, W^
), doubles
(D:
, D^
), floats (F:
, F^
) and characters
(C:
, C^
) in two flavours: a value-flavoured local (defined
with W:
, D:
etc.) produces its value and can be changed
with TO
. A variable-flavoured local (defined with W^
etc.)
produces its address (which becomes invalid when the variable's scope is
left). E.g., the standard word emit
can be defined in terms of
type
like this:
: emit { C^ char* -- } char* 1 type ;
A local without type specifier is a W:
local. Both flavours of
locals are initialized with values from the data or FP stack.
Currently there is no way to define locals with user-defined data structures, but we are working on it.
Gforth allows defining locals everywhere in a colon definition. This poses the following questions: