On 16/03/2024 5:37 am, Paul Rubin wrote:
...
At least in gforth, VARIABLEs are initialized to 0. That seems like a
good thing for implementations to do ingeneral.
That's something I'd do for VALUEs should I move to omit the numeric
prefix at creation. By automatically initializing VALUEs with 0, I can pretend - if only to myself - that VALUEs are different from VARIABLEs.
On 16/03/2024 4:15 pm, dxf wrote:
On 16/03/2024 5:37 am, Paul Rubin wrote:
...
At least in gforth, VARIABLEs are initialized to 0. That seems like a
good thing for implementations to do ingeneral.
That's something I'd do for VALUEs should I move to omit the numeric
prefix at creation. By automatically initializing VALUEs with 0, I can
pretend - if only to myself - that VALUEs are different from VARIABLEs.
... and CONSTANTs
I don't know who first coined 'VALUE' but based on his 1984 handout:
https://pastebin.com/p5P5EVTm
Martin Tracy seems as good a suspect as any. Tracy promoted IS as
the mechanism for changing a VALUE. Why he didn't use TO is unclear.
Perhaps it was to avoid clashing with Bartholdi's TO which was aimed
squarely at VARIABLEs. Rather than Bartholdi's radical changing of
VARIABLE, Tracy introduced a new data type - that of VALUE.
Unlike Bartholdi's VARIABLE, Tracy's new data type had aspects more
in common with CONSTANT - namely supplying a value at definition time:
n VALUE name
And it's quite misleading.
AFAICS Tracy made the correct choice of introducing a new data type
rather than trying to redefine VARIABLE. Where he got it wrong IMO,
is in making VALUE appear as a CONSTANT - something ANS went along
with, presumably as it was by then 'common practice'. While I don't
see Standard Forth changing it as it would literally break every
program written using VALUE, I have fewer such qualms besides which
a mistake is a mistake.
On 16/03/2024 4:15 pm, dxf wrote:
On 16/03/2024 5:37 am, Paul Rubin wrote:
...
At least in gforth, VARIABLEs are initialized to 0. That seems like a >>>> good thing for implementations to do ingeneral.
That's something I'd do for VALUEs should I move to omit the numeric
prefix at creation. By automatically initializing VALUEs with 0, I can
pretend - if only to myself - that VALUEs are different from VARIABLEs.
... and CONSTANTs
I don't know who first coined 'VALUE' but based on his 1984 handout:
https://pastebin.com/p5P5EVTm
Martin Tracy seems as good a suspect as any. Tracy promoted IS as
the mechanism for changing a VALUE. Why he didn't use TO is unclear.
Perhaps it was to avoid clashing with Bartholdi's TO which was aimed
squarely at VARIABLEs. Rather than Bartholdi's radical changing of
VARIABLE, Tracy introduced a new data type - that of VALUE.
Unlike Bartholdi's VARIABLE, Tracy's new data type had aspects more
in common with CONSTANT - namely supplying a value at definition time:
n VALUE name
And it's quite misleading.
Agree. It would be better to have VALUE ( "name" -- )
And the initial value for "name" should be 0.
But, "VALUE" does not imply a new *data type*, but only a new
type/subtype of named Forth definitions, if you like.
[...]
AFAICS Tracy made the correct choice of introducing a new data type
rather than trying to redefine VARIABLE. Where he got it wrong IMO,
is in making VALUE appear as a CONSTANT - something ANS went along
with, presumably as it was by then 'common practice'. While I don't
see Standard Forth changing it as it would literally break every
program written using VALUE, I have fewer such qualms besides which
a mistake is a mistake.
Another name only can be introduced.
Ruvim
On 2024-03-19 04:48, dxf wrote:
On 16/03/2024 4:15 pm, dxf wrote:
On 16/03/2024 5:37 am, Paul Rubin wrote:
...
At least in gforth, VARIABLEs are initialized to 0. That seems like a >>>> good thing for implementations to do ingeneral.
That's something I'd do for VALUEs should I move to omit the numeric
prefix at creation. By automatically initializing VALUEs with 0, I can >>> pretend - if only to myself - that VALUEs are different from VARIABLEs.
... and CONSTANTs
I don't know who first coined 'VALUE' but based on his 1984 handout:
https://pastebin.com/p5P5EVTm
Martin Tracy seems as good a suspect as any. Tracy promoted IS as
the mechanism for changing a VALUE. Why he didn't use TO is unclear.
Perhaps it was to avoid clashing with Bartholdi's TO which was aimed
squarely at VARIABLEs. Rather than Bartholdi's radical changing of
VARIABLE, Tracy introduced a new data type - that of VALUE.
Unlike Bartholdi's VARIABLE, Tracy's new data type had aspects more
in common with CONSTANT - namely supplying a value at definition time:
n VALUE name
And it's quite misleading.
Agree. It would be better to have VALUE ( "name" -- )
And the initial value for "name" should be 0.
But, "VALUE" does not imply a new *data type*, but only a new
type/subtype of named Forth definitions, if you like.
[...]
AFAICS Tracy made the correct choice of introducing a new data type
rather than trying to redefine VARIABLE. Where he got it wrong IMO,
is in making VALUE appear as a CONSTANT - something ANS went along
with, presumably as it was by then 'common practice'. While I don't
see Standard Forth changing it as it would literally break every
program written using VALUE, I have fewer such qualms besides which
a mistake is a mistake.
Another name only can be introduced.
In article <utbptf$peiu$1@dont-email.me>, Ruvim <ruvim.pinka@gmail.com> wrote:[...]
On 2024-03-19 04:48, dxf wrote:
[...]Unlike Bartholdi's VARIABLE, Tracy's new data type had aspects more
in common with CONSTANT - namely supplying a value at definition time:
n VALUE name
And it's quite misleading.
Agree. It would be better to have VALUE ( "name" -- )
And the initial value for "name" should be 0.
AFAICS Tracy made the correct choice of introducing a new data type
rather than trying to redefine VARIABLE.
But, "VALUE" does not imply a new *data type*, but only a new
type/subtype of named Forth definitions, if you like.
I like your observation that VALUE and VARIABLE is in fact the same
datatype. Maybe that explains my dislike for VALUE.
I think introducing an overloaded parsing word TO was a much bigger
mistake.
Much simpler is eliminating TO by exploiting Forth's
redefinition rules ...
https://pastebin.com/p5P5EVTm...
Rather than Bartholdi's radical changing of
VARIABLE, Tracy introduced a new data type - that of VALUE.
Unlike Bartholdi's VARIABLE, Tracy's new data type had aspects more
in common with CONSTANT - namely supplying a value at definition time:
n VALUE name
I think introducing an overloaded parsing word TO was a much bigger...
mistake.
TO can't be
postponed in ANS Forth.
On 19/03/2024 10:37, Ruvim wrote:[...]
On 2024-03-19 04:48, dxf wrote:
AFAICS Tracy made the correct choice of introducing a new data type
rather than trying to redefine VARIABLE. Where he got it wrong IMO,
is in making VALUE appear as a CONSTANT - something ANS went along
with, presumably as it was by then 'common practice'. While I don't
see Standard Forth changing it as it would literally break every
program written using VALUE, I have fewer such qualms besides which
a mistake is a mistake.
Another name only can be introduced.
I think introducing an overloaded parsing word TO was a much bigger
mistake.
Much simpler is eliminating TO by exploiting Forth's
redefinition rules:
: val create , ;
111 val a
: a! a ! ; \ Replaces TO a
: a+! a +! ; \ Replaces +TO a
: a a @ ; \ Hide the CREATEd a
a 222 a! a 99 a+! a ( -- 111 222 321 ) .s
The CREATEd value a can be hidden in a separate wordlist if you dislike
the order of the definitions.
Postponing versions can be defined for compilation.
TO can't be postponed in ANS Forth.
Incidentally I'd like to see VALUEs extended much as described in N J Nelson's papers in EuroForth 2020 and 2022
http://www.euroforth.org/ef20/papers/nelson.pdf
http://www.euroforth.org/ef22/papers/nelson-values.pdf
but that still uses a parsing operator -> instead of TO
On 2024-03-19 04:48, dxf wrote:
...
Unlike Bartholdi's VARIABLE, Tracy's new data type had aspects more
in common with CONSTANT - namely supplying a value at definition time:
n VALUE name
And it's quite misleading.
Agree. It would be better to have VALUE ( "name" -- )
And the initial value for "name" should be 0.
But, "VALUE" does not imply a new *data type*, but only a new type/subtype of named Forth definitions, if you like.
AFAICS Tracy made the correct choice of introducing a new data type
rather than trying to redefine VARIABLE. Where he got it wrong IMO,
is in making VALUE appear as a CONSTANT - something ANS went along
with, presumably as it was by then 'common practice'. While I don't
see Standard Forth changing it as it would literally break every
program written using VALUE, I have fewer such qualms besides which
a mistake is a mistake.
Another name only can be introduced.
dxf <dxforth@gmail.com> writes:
https://pastebin.com/p5P5EVTm...
Rather than Bartholdi's radical changing of
VARIABLE, Tracy introduced a new data type - that of VALUE.
It's a new name, not a new data type.
Unlike Bartholdi's VARIABLE, Tracy's new data type had aspects more
in common with CONSTANT - namely supplying a value at definition time:
n VALUE name
That's very sensible, and fig-Forth also supplied an initial value to
a variable:
n VARIABLE name \ fig-Forth
Unfortunately, Forth-79 standardized VARIABLE to create an
uninitialized variable, and later standards kept this mistake. So now
I always have to write something like
VARIABLE name n name !
On 20/03/2024 4:21 am, Anton Ertl wrote:
Unfortunately, Forth-79 standardized VARIABLE to create an
uninitialized variable, and later standards kept this mistake. So now
I always have to write something like
VARIABLE name n name !
What do you do when your application restarts? The values assigned at >creation-time have likely changed.
What do you do when your application restarts? The values assigned at creation-time have likely changed.
dxf wrote:
[..]
What do you do when your application restarts? The values assigned at
creation-time have likely changed.
That's a good point I've not seen addressed yet. In my current circuit simulation work, I need variables that either reset to their 'boot' value (e.g., 0), or retain the value computed during the last run (e.g. variables updated by other applications|computing nodes started by my own program).
On 19/03/2024 9:37 pm, Ruvim wrote:
On 2024-03-19 04:48, dxf wrote:
...
AFAICS Tracy made the correct choice of introducing a new data type
rather than trying to redefine VARIABLE. Where he got it wrong IMO,
is in making VALUE appear as a CONSTANT - something ANS went along
with, presumably as it was by then 'common practice'. While I don't
see Standard Forth changing it as it would literally break every
program written using VALUE, I have fewer such qualms besides which
a mistake is a mistake.
Another name only can be introduced.
I didn't consider that - remove VALUE from my sources but retain the
word for backward compatibility. It's what I did with ANS CASE when
I decided it was time for it to go. Now to find a suitable name. Not
keen on VAL or VAR as they're too close...
I think introducing an overloaded parsing word TO was a much bigger
mistake. Much simpler is eliminating TO by exploiting Forth's
redefinition rules:
: val create , ;
111 val a
: a! a ! ; \ Replaces TO a
: a+! a +! ; \ Replaces +TO a
: a a @ ; \ Hide the CREATEd a
a 222 a! a 99 a+! a ( -- 111 222 321 ) .s
The CREATEd value a can be hidden in a separate wordlist if you dislike
the order of the definitions.
Postponing versions can be defined for compilation. TO can't be
postponed in ANS Forth.
Incidentally I'd like to see VALUEs extended much as described in N J Nelson's papers in EuroForth 2020 and 2022
http://www.euroforth.org/ef20/papers/nelson.pdf
http://www.euroforth.org/ef22/papers/nelson-values.pdf
but that still uses a parsing operator -> instead of TO
Gerry Jackson wrote:
I think introducing an overloaded parsing word TO was a much bigger
mistake.
Water under the bridge, anyhow
- in most tokenized systems a compiled TO doesn't parse
(but interpreted yes, so it's not a real win)
- more unfortunate imo is that locals and global values
are also written with TO
Much simpler is eliminating TO by exploiting Forth's
redefinition rules ...
With VALUEs "as ojects" (with 3 data actions, using Rosen's wording)
you don't need to redefine TO with every new value type: F.ex. in
MinForth complex number values are defined thru:
: ZVALUE \ ( r: r1 r2 <name> -- ) double fp-number value
['] z@ ['] z! ['] z+ _(value) f, f, ;
That's all. Ready to use. No need to adapt TO or +TO.
dxf <dxforth@gmail.com> writes:
On 20/03/2024 4:21 am, Anton Ertl wrote:
Unfortunately, Forth-79 standardized VARIABLE to create an
uninitialized variable, and later standards kept this mistake. So now
I always have to write something like
VARIABLE name n name !
What do you do when your application restarts? The values assigned at >>creation-time have likely changed.
I typically restart the application by restarting the Forth system and >reloading the application source.
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
VFX Forth defines the operators such as TO and -> as immediate words that justIn 4tH, VALUE is considered to be a dereferenced VARIABLE. As you all
set
a variable. The child of value just inspects the variable. No parsing needed and it
fits the "as if parsing" requirement of ANS/Forth2012. IMHO it also leads to simpler
implementation and allows for reuse of operators.
With VALUE DVALUE FVALUE LOCAL DLOCAL FLOCAL etc. and message FROM TO
+TO CLR etc. I devoted a chapter of tforth (1993, nowadays probably present in iforth) to explain that these are in effect considered messages to objects.
Polymorphism is the excuse to use the same message for different objects. That is the only reason I came to terms with this.
The value-something is an object and to-etc are messages.
...
Nobody needs VALUEs that only conceal a few @s
I typically restart the application by restarting the Forth system and >>reloading the application source.
With ample memory it is not worthwhile to restart the Forth system.
With ciforth making executables is easy.
This alternative allows to
pass parameters to the executable.
#! /usr/bin/env gforth
albert@spenarnc.xs4all.nl writes:Merely inconvenient.
I typically restart the application by restarting the Forth system and >>>reloading the application source.
With ample memory it is not worthwhile to restart the Forth system.
As if that was costly.
It is so easy that it pays off not loading the source several times,With ciforth making executables is easy.
Easy is still harder than doing nothing.
With a Forth system and an OS (like Unix) that have good support for >executing scripts, the Forth source code can just serve as script; if
you want to call the script without mentioning the Forth system, you
can put the Forth system in the hash-bang line in Unix, e.g.
#! /usr/bin/gforth
or
#! /usr/bin/env gforth
as first line (the latter is beneficial if you don't know whether
gforth is in /usr/bin or /usr/local/bin on the systems where the
script is invoked). Ok, you still have to do that and make the file >executable, but you don't have to repeat that every time you change
the program source, while you have to rebuild the binary executable
every time, however easy that may be.
Here's an example:
[/tmp:147807] cat <<EOF >example
#! /usr/bin/env gforth
: echo ( -- )
begin
next-arg 2dup 0 0 d<> while
type space
repeat
2drop ;
echo cr bye
EOF
[/tmp:147808] chmod +x example
[/tmp:147809] ./example a b c d
a b c d
If I edit example, I don't have to repeat the chmod.
- anton
What do you do when your application restarts? The values assigned at creation-time have likely changed.
dxf <dxforth@gmail.com> writes:
https://pastebin.com/p5P5EVTm...
Rather than Bartholdi's radical changing of
VARIABLE, Tracy introduced a new data type - that of VALUE.
It's a new name, not a new data type.
Unlike Bartholdi's VARIABLE, Tracy's new data type had aspects more
in common with CONSTANT - namely supplying a value at definition time:
n VALUE name
That's very sensible, and fig-Forth also supplied an initial value to
a variable:
n VARIABLE name \ fig-Forth
Unfortunately, Forth-79 standardized VARIABLE to create an
uninitialized variable, and later standards kept this mistake. So now
I always have to write something like
VARIABLE name n name !
On 2024-03-19 21:21, Anton Ertl wrote:
dxf <dxforth@gmail.com> writes:
https://pastebin.com/p5P5EVTm...
Rather than Bartholdi's radical changing of
VARIABLE, Tracy introduced a new data type - that of VALUE.
It's a new name, not a new data type.
Unlike Bartholdi's VARIABLE, Tracy's new data type had aspects more
in common with CONSTANT - namely supplying a value at definition time:
n VALUE name
That's very sensible, and fig-Forth also supplied an initial value to
a variable:
n VARIABLE name \ fig-Forth
Unfortunately, Forth-79 standardized VARIABLE to create an
uninitialized variable, and later standards kept this mistake. So now
I always have to write something like
VARIABLE name n name !
And most likely n is 0, isn't it? Therefore, a requirement to systems to initialize variables by zero simplifies programs.
On 2024-03-19 21:21, Anton Ertl wrote:
Unfortunately, Forth-79 standardized VARIABLE to create an
uninitialized variable, and later standards kept this mistake. So now
I always have to write something like
VARIABLE name n name !
And most likely n is 0, isn't it?
Therefore, a requirement to systems to
initialize variables by zero simplifies programs.
If an uninitialized variable is required by a program, it can be defined >using "BUFFER:".
To define a variable with an explicitly specified initial value, why not >create a word like this:
: in-var ( n "name" -- )
variable
latest-name name> execute !
;
Another observation. "DEFER" (which is similar to "VALUE") does not
accept an initial value. Well, in most use cases this value yet unknown.
But a non-zero initial value is also unknown for many use cases of
"VALUE" and "VARIABLE".
If the value is not yet known, the deferred word must not be called.
So a good initialization value produces an exception. In Gforth it
produces a warning for now, but after >15 years of warnings, it's time
to actually produce an exception.
Ruvim <ruvim.pinka@gmail.com> writes:
On 2024-03-19 21:21, Anton Ertl wrote:
Unfortunately, Forth-79 standardized VARIABLE to create an
uninitialized variable, and later standards kept this mistake. So now
I always have to write something like
VARIABLE name n name !
And most likely n is 0, isn't it?
What makes you think so? See the VALUE results below.
Therefore, a requirement to systems to
initialize variables by zero simplifies programs.
You mean that it is significantly more complex to write
0 fig-variable foo
than to write
gforth-variable foo
I don't think so. I think that the FIG-VARIABLE line makes it clear
that the intention is to initialize to zero, whereas the
GFORTH-VARIABLE line looks like the programmer might have forgotten to initialize the variable.
Because of that uncertainty and for portability
(and the failure of standard VARIABLE to initialize), a
programmer will find the urge to write the latter as
variable foo 0 foo !
even when writing a Gforth-specific program. Where is the
simplification now?
If an uninitialized variable is required by a program, it can be defined
using "BUFFER:".
There is no requirement for non-initialization unless your program
works with whatever earlier code has left in that memory, and that's
likely to be a bad idea for the memory allocated with VARIABLE or
BUFFER:.
Certainly nobody has complained that Gforth's VARIABLE does
not satisfy their requirement for and uninitialized variable.
If you mean that there is no requirement for initialization,
initialized variables of course satisfy this non-requirement.
To define a variable with an explicitly specified initial value, why not
create a word like this:
: in-var ( n "name" -- )
variable
latest-name name> execute !
;
or, in standard Forth:
: in-var ( n "name" -- )
create , ;
Yes, such a word is a good idea, although I would use a different name.
Another observation. "DEFER" (which is similar to "VALUE") does not
accept an initial value. Well, in most use cases this value yet unknown.
If the value is not yet known, the deferred word must not be called.
So a good initialization value produces an exception. In Gforth it
produces a warning for now, but after >15 years of warnings, it's time
to actually produce an exception.
But a non-zero initial value is also unknown for many use cases of
"VALUE" and "VARIABLE".
Looking at the 37 uses of VALUE in the Gforth image (outside the
kernel AFAICS), 20 initialize to 0 and 1 to FALSE, leaving 16 uses
that initialize to non-zero values. "Most likely" 0?
Anton Ertl wrote:
If the value is not yet known, the deferred word must not be called.
So a good initialization value produces an exception. In Gforth it
produces a warning for now, but after >15 years of warnings, it's time
to actually produce an exception.
Here DEFERs default to NOP, like VARIABLEs to 0. Never had an issue with this.
Anton Ertl wrote:
If the value is not yet known, the deferred word must not be called.
So a good initialization value produces an exception. In Gforth it
produces a warning for now, but after >15 years of warnings, it's time
to actually produce an exception.
Here DEFERs default to NOP, like VARIABLEs to 0. Never had an issue with this.
On 2024-03-19 18:42, Gerry Jackson wrote:[...]
On 19/03/2024 10:37, Ruvim wrote:
Another name only can be introduced.
I think introducing an overloaded parsing word TO was a much bigger
mistake.
Much simpler is eliminating TO by exploiting Forth's redefinition rules:
: val create , ;
111 val a
: a! a ! ; \ Replaces TO a
: a+! a +! ; \ Replaces +TO a
: a a @ ; \ Hide the CREATEd a
a 222 a! a 99 a+! a ( -- 111 222 321 ) .s
I prefer this way over "TO" too. In my implementation [1], the getter
and setter are created automatically:
slot( a b )
111 222 set( a b )
a b + set-a a . \ "333"
Incidentally I'd like to see VALUEs extended much as described in N J
Nelson's papers in EuroForth 2020 and 2022
http://www.euroforth.org/ef20/papers/nelson.pdf
http://www.euroforth.org/ef22/papers/nelson-values.pdf
but that still uses a parsing operator -> instead of TO
I dislike "TO"-based approach/syntax for arrays and structures.
This approach supposes, that the array "X" is actually a kind of
fetching from index (like "@"):
X ( index -- data )
And "TO X" is a kind of storing to index (like "!"):
TO X ( data index -- )
It's confusing. And it does not allow to pass such an array as an argument.
| Sysop: | DaiTengu |
|---|---|
| Location: | Appleton, WI |
| Users: | 914 |
| Nodes: | 10 (1 / 9) |
| Uptime: | 233:25:49 |
| Calls: | 12,157 |
| Files: | 186,518 |
| Messages: | 2,232,635 |