A Value behaves like a Constant, but it can be changed.
TO and +TO are parsing words that change a value.
Alternatively, you can change a value v by writing ->v
(equivalent to TO v) or +>v (equivalent to +TO
v).
Here are some examples:
12 value apples \ Define APPLES with an initial value of 12 34 to apples \ Change the value of APPLES. TO is a parsing word 1 +to apples \ Increment APPLES. Non-standard usage. apples \ puts 35 on the top of the stack.
Value ( w "name" – ) core-ext “Value”
Define name with the initial value w; this value can be
changed with to name or ->name ( w2 –
) or with +to name or +>name ( n|u –
).
name execution: ( – w3 )
AValue ( w "name" – ) gforth-0.6 “AValue”
Like value, but defines a value for an address
(this only makes a difference in the cross-compiler).
2Value ( w1 w2 "name" – ) double-ext “two-value”
Define name with the initial values w1 w2; these values
can be changed with to name or ->name
( w3 w4 – ), or with +to name or
+>name ( d – ).
name execution: ( –
w5 w6 )
fvalue ( r "name" – ) floating-ext “f-value”
Define name with the initial value r; this value can be
changed with to name, ->name, +to
name or +>name ( r2 – ).
name
execution: ( – r3 )
TO ( value "name" – ) core-ext “TO”
Changes the value of name to be equal to value. The type
of value depends on the type of name. An alternative
syntax is to write ->name.
+TO ( value "name" – ) gforth-1.0 “+TO”
Adds value to the value of name. The type of value
depends on the type of name. An alternative syntax is to write
+>name.
Words that produce their value on execution and that can be changed
with to or +to are called value-flavoured (in contrast
to the variable-flavoured words that produce their address on
execution). They are defined be some of the words listed above, but
also by some locals definitions words (see Locals definitions words) and some field definition words (see Value-Flavoured and Defer-Flavoured Fields).
Sometimes you want to take the address of a value-flavoured word.
Because this has some potential performance disadvantages, Gforth asks
you to be explicit about it, and define the word as addressable. Once
you have done that, you can get the address with addr. The
following example is equivalent to the one above:
12 addressable: value apples 34 addr apples ! \ Change the value of APPLES. ADDR is a parsing word 1 +to apples \ Increment APPLES addr apples @ \ puts 35 on the top of the stack.
addressable: ( – ) gforth-experimental “addressable:”
Addressable: should be used in front of a defining word
for a value-flavoured word (e.g., value). It allows to
use addr on the word defined by that defining word.
addr ( "name" – addr ) gforth-1.0 “addr”
Addr is the address where the value of name is stored.
Name has to be defined with any value-flavoured defining word
(e.g. value) preceded by addressable:.
For now using addr on a non-addressable: value results
in a warning. In the future, when we change the code generation in a
way that results in potentially faster code for
non-addressable: values, but where the use of addr on
such values could produce unexpected results, such usage will result
in an error.