6 Glossary

6.2.2405 VALUE CORE EXT

( x "<spaces>name" -- )

Skip leading space delimiters. Parse name delimited by a space. Create a definition for name with the execution semantics defined below, with an initial value equal to x.

name is referred to as a "value".

name Execution:

( -- x )

Place x on the stack. The value of x is that given when name was created, until the phrase x TO name is executed, causing a new value of x to be assigned to name.

TO name Run-time:

( x -- )

Assign the value x to name.

See:

Rationale:

Typical use:
0 VALUE data

: EXCHANGE ( n1 -- n2 ) data SWAP TO data ;

EXCHANGE leaves n1 in data and returns the prior value n2.

Testing:

T{  111 VALUE v1 -> }T
T{ -999 VALUE v2 -> }T
T{ v1 ->  111 }T
T{ v2 -> -999 }T
T{ 222 TO v1 -> }T
T{ v1 -> 222 }T

T{ : vd1 v1 ; -> }T
T{ vd1 -> 222 }T

T{ : vd2 TO v2 ; -> }T
T{ v2 -> -999 }T
T{ -333 vd2 -> }T
T{ v2 -> -333 }T
T{ v1 ->  222 }T

ContributeContributions

EricBlakeavatar of EricBlake [387] Compilation of a VALUE child word should not inline its current valueSuggested Testcase2025-07-26 18:27:56

The existing tests of VALUE do not exercise what happens if a value word is compiled, its contents then changed with TO, and then that earlier compilation is executed.

I was working on an optimizing version of COMPILE, in my implementation, and noticed (along with other LITERAL/LIT, behaviors) that when compiling a word that is a child of CONSTANT or VALUE, I could inline the value produced by executing those child words at compilation time, and nearly made the mistake of doing the same for children of VARIABLE. The current testsuite did not flag my mistake, even though it is not in line with traditional semantics. Therefore, I suggest adding this after the existing tests:

T{ 333 TO v1 -> }T
T{ vd1 -> 333 }T

to prove that vd1 was compiled with a reference to the dynamic contents of v1, and not to the inline value that v1 happened to have at the time vd1 was defined.

Reply New Version