One problem I keep having while learning Forth is that the language has changed in the past 30 years but some of the most in-depth documentation is still stuck in the land of WORD (instead of PARSE-NAME). For instance, I am finally getting around to coding VALUE for Tali Forth, and I'm slightly at a loss why you would still want to use VARIABLE except for special cases: VALUE initializes and gives you the, ah, value you saved instead of the address where it lives.
Compare this to:
(Typed from memory, can't test at the moment, sorry if typos) Am I missing something here, possibly in connection with TO, or is VARIABLE just outdated? Maybe we should start a series of tutorials with more modern Forth examples to complement the current literature.

I am not as far along in learning Forth as you are, but it looks to me (from your example) that VALUE is akin to a constant declaration, whereas VARIABLE is more like a variable declaration. Of course, you didn't show how easy or difficult it is to change a VALUE on the fly, but it also reminds me of the old "pass by value" vs. "pass by reference" argument when discussing function parameters.

Mike

Based on the example provided, the behavior & usage of VALUE appear identical to that of Fig-Forth CONSTANT, so I'd say Mike's right. Which raises the question, why substitute a new name for an already-existing function?

FWIW, in my own code I sometimes (ab-)use CONSTANT to implement what is, in fact, a variable. This boosts performance in the very common case where a value is read frequently but written to infrequently. Writes are accomplished with a ! to the Parameter Field of the so-called constant, and of course that in itself yields no benefit. But reads are accelerated because it's unnecessary to explicitly use @. It takes one word, not two, to get that value on stack.

It's a handy trick, but the code's readability is compromised when a word defined as a CONSTANT returns a value which is not constant. Maybe that's why the less suggestive name VALUE was substituted. (Corrections and additional info welcome! I have not kept up to date on standards discussions.)

-- Jeff

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

A VALUE is not a CONSTANT. It's an alternate implementation of a variable. As follows:

VARIABLE FOO
FOO @ ( to get the contents of FOO )
n FOO ! ( to store n into FOO )

x VALUE BAR
BAR ( to get the contents of BAR, currently x )
n TO BAR ( to store n into BAR )

I've lost count of the number of different ways this has been implemented. People who come from other languages like the fact that referencing the name of a variable gives you its value (with no need for a @ operator).

There are two disadvantages to VALUEs: First, there's no agreed way to implement VALUEs for anything larger than a single cell. Second, there's no agreed way to do call by reference. (How do you pass the address of a VALUE to a function?)

_________________
Because there are never enough Forth implementations: http://www.camelforth.com

Brad, thank you (as always) for the clarification. Hadn't though of the reference problem ...

When the value stored changes frequently, VARIABLE is the way to go.
Also, there is no easy way to implement something like +! with VALUE.

In his book Thinking Forth, Leo Brodie gives an example of hiding information to minimize the effects of design changes by localizing things that might change. He claims that direct memory access with @ and ! makes it possible. In his example, he uses a variable APPLES to keep a tally of apples. Then at the eleventh hour after a lot of code using APPLES has been written, a tally must be kept of two different kinds of apples, red and green. Leo Brodie proceeds to show how APPLES can be redefined as a colon definition which can be set to return the correct location for each tally.

To quote Leo Brodie "If we first say RED, then we can use APPLES to refer to red apples. If we say GREEN, we can use it to refer to green apples. We didn't need to change the syntax of any existing code that uses APPLES. We can still say
20 APPLES !
and
1 APPLES +!"

Cheers,
Jim