VALUE - the good, the bad and the ugly

...
At least in gforth, VARIABLEs are initialized to 0. That seems like a
good thing for implementations to do ingeneral.

... and CONSTANTs
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
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.

[...]

Post by dxf
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

a***@spenarnc.xs4all.nl

2024-03-19 14:38:10 UTC

...
At least in gforth, VARIABLEs are initialized to 0. That seems like a
good thing for implementations to do ingeneral.

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.
[...]

Another name only can be introduced.

In projecteuler problems there is a size that is useful for testing
1000 CONSTANT size
For production the size should be e.g. 10^9.
I like to pass the size as a parameter to a turnkey program,
but more likely than not, this program has O(10^9) bytes.
This can be solved in a system dependant matter by
1,000,000,000 'size >DFA !
(and later 'buffer size CELLS REALLOT )
In this situation I'm tempted to use VALUE .
It is hardly a win, because I patch the datafield of buffers anyhow
by REALLOT, this cannot be helped.

I like your observation that VALUE and VARIABLE is in fact the same
datatype. Maybe that explains my dislike for VALUE.

Post by Ruvim
Ruvim

Groetjes Albert

--
Don't praise the day before the evening. One swallow doesn't make spring.
You must not say "hey" before you have crossed the bridge. Don't sell the
hide of the bear until you shot it. Better one bird in the hand than ten in
the air. First gain is a cat purring. - the Wise from Antrim -

Ruvim

2024-03-19 16:01:29 UTC

Post by a***@spenarnc.xs4all.nl

[...]

Post by dxf
Unlike Bartholdi's VARIABLE, Tracy's new data type had aspects more
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.

Post by dxf
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.

[...]

Post by a***@spenarnc.xs4all.nl
I like your observation that VALUE and VARIABLE is in fact the same
datatype. Maybe that explains my dislike for VALUE.

My note just about terminology.

The children words of VALUE and VARIABLE *contain* data objects of the
same size and the same most general type "unspecified cell".

The children words of FVALUE and 2VALUE *contain* data objects of other
data types. But they don't imply *new* data types too.

A data type is a set, and a data type of a data object is a set to which
this data object belongs.

In Forth, a definition is not a data object. A particular execution
token is a data object, as well as a name token.

--
Ruvim

Gerry Jackson

2024-03-19 14:42:24 UTC

...
At least in gforth, VARIABLEs are initialized to 0. That seems like a
good thing for implementations to do ingeneral.

Agree. It would be better to have VALUE ( "name" -- )
And the initial value for "name" should be 0.

I disagree - it's too trivial to worry about

But, "VALUE" does not imply a new *data type*, but only a new
type/subtype of named Forth definitions, if you like.
[...]

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

--
Gerry

minforth

2024-03-19 17:31:45 UTC

Post by Gerry Jackson
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

Post by Gerry Jackson
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.

a***@spenarnc.xs4all.nl

2024-03-20 12:34:44 UTC

Post by minforth

Post by Gerry Jackson
I think introducing an overloaded parsing word TO was a much bigger
mistake.

Post by Gerry Jackson
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

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.

[The alternative for OO is my generalised CREATE DOES>.
The latter is more Forth-like IMO.]

Post by minforth
: ZVALUE \ ( r: r1 r2 <name> -- ) double fp-number value
That's all. Ready to use. No need to adapt TO or +TO.

Groetjes Albert

minforth

2024-03-20 19:00:07 UTC

Post by a***@spenarnc.xs4all.nl
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.

I also see this as significant added value. Nobody needs VALUEs that only conceal
a few @s and memory addresses disguised as VARIABLE.

I find the use of method-based VALUEs particularly practical for dynamic arrays and
dynamic strings. The entire allocation, resizing and freeing of heap memory can be
done opaquely and without garbage collectors. For user applications there is practically
no significant difference between standard strings and dynamic strings. Very helpful.

dxf

2024-03-21 02:03:02 UTC

...

The following summarizes how VALUE was explained to me on c.l.f. :

"If you are interested in a value which often changes, use a VARIABLE. If
it seldom changes, use a VALUE, and if it never changes, use a CONSTANT."
- 'Mastering FORTH'

It still resonates after all these years. OTOH I've never been convinced by the
'values should replace variables' arguments. Differentiation aids readability,
not hinders it. That said, I've not felt the need to provide 2VALUE or FVALUE.
I have locals for users that may want them - but not seen any evidence of them
being used.

Anton Ertl

2024-03-19 18:15:34 UTC

Post by Gerry Jackson
I think introducing an overloaded parsing word TO was a much bigger
mistake.

...

Post by Gerry Jackson
TO can't be
postponed in ANS Forth.

Gforth implements quite a bit of mechanism to deal with VALUEs, but I
am mostly happy with the result:

Concerning parsing: TO still works, but the nicer way to change values
is with the to-recognizer. Instead of "TO X", you write "->X". The
"->X" syntax can be POSTPONEd:

0 value x
: my->x postpone ->x ; immediate
: bar my->x ;
5 bar
x . \ prints 5

Concerning overloaded: Every word has an EXECUTE method and a (TO)
method (for most words that is NO-TO, but for VALUEs it's VALUE-TO,
for FVALUEs it's FVALUE-TO, etc.). TO and the to-recognizer call
(TO).

I write that I am "mostly" happy because (to) covers not just TO, but
also +TO etc. through an additional dispatch table; I think it would
be simpler to have a (+TO) method in the ordinary word methods. But
there are also some arguments in favour of the separate to-table
approach.

For more information about this stuff, read:

@InProceedings{paysan&ertl19,
author = {Bernd Paysan and M. Anton Ertl},
title = {The new {Gforth} Header},
crossref = {euroforth19},
pages = {5--20},
url = {http://www.euroforth.org/ef19/papers/paysan.pdf},
url-slides = {http://www.euroforth.org/ef19/papers/paysan-slides.pdf},
video = {https://wiki.forth-ev.de/doku.php/events:ef2019:header},
OPTnote = {refereed},
abstract = {The new Gforth header is designed to directly
implement the requirements of Forth-94 and
Forth-2012. Every header is an object with a fixed
set of fields (code, parameter, count, name, link)
and methods (\texttt{execute}, \texttt{compile,},
\texttt{(to)}, \texttt{defer@}, \texttt{does},
\texttt{name>interpret}, \texttt{name>compile},
\texttt{name>string}, \texttt{name>link}). The
implementation of each method can be changed
per-word (prototype-based object-oriented
programming). We demonstrate how to use these
features to implement optimization of constants,
\texttt{fvalue}, \texttt{defer}, \texttt{immediate},
\texttt{to} and other dual-semantics words, and
\texttt{synonym}.}
}

@Proceedings{euroforth19,
title = {35th EuroForth Conference},
booktitle = {35th EuroForth Conference},
year = {2019},
key = {EuroForth'19},
url = {http://www.euroforth.org/ef19/papers/proceedings.pdf}
}

- anton

--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: https://forth-standard.org/
EuroForth 2023: https://euro.theforth.net/2023

Ruvim

2024-03-19 20:59:30 UTC

[...]

Post by Gerry Jackson

Another name only can be introduced.

I think introducing an overloaded parsing word TO was a much bigger
mistake.

Why do you think it's a mistake?

Post by Gerry Jackson
Much simpler is eliminating TO by exploiting Forth's
: val create , ;
111 val a
: a! a ! ; \ Replaces TO a
: a+! a +! ; \ Replaces +TO 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"

Post by Gerry Jackson
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.

If you mean "POSTPONE TO" — yes, formally is is not allowed. And the
only reason for that is that "FIND" is underspecified in Forth-94 (and
the same in Forth-2012). Since, if "FIND" were well specified (for
example, as in my clarification [2]), "POSTPONE" could be defined
through "FIND" and then it will be pretty applicable to "TO". In fact,
the standard "FIND" is sufficiently specified for
single-xt+immediate-flag systems only, and this approach correctly works
for them.

In Forth-2012, "POSTPONE" can be defined through "NAME>COMPILE" [3], and
then it will be also applicable to "TO". So it's an outdated restriction
in Forth-2012.

Concerning postponing "TO X", this can be achieved as
"[: TO X ;] COMPILE,"

Post by Gerry Jackson
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.

[1] Defining slots
https://gist.github.com/ruv/438d57d0af6a38e616efb59b43795e1b#file-slot-fth

[2] Clarify FIND
https://forth-standard.org/proposals/clarify-find-more-classic-approach?hideDiff#reply-682

[3] Redefined "POSTPONE" can be applied to "TO"
https://github.com/ForthHub/discussion/discussions/103#solution

--
Ruvim

Ruvim

2024-03-26 15:24:41 UTC

[...]

Post by Gerry Jackson

Post by Ruvim
Another name only can be introduced.

I think introducing an overloaded parsing word TO was a much bigger
mistake.
: val create , ;
111 val a
: a! a ! ; \ Replaces TO a
: a+! a +! ; \ Replaces +TO 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
slot( a b )
111 222 set( a b )
a b + set-a a . \ "333"

[...]

I dislike "TO"-based approach/syntax for arrays and structures.
This approach supposes, that the array "X" is actually a kind of
X ( index -- data )
TO X ( data index -- )
It's confusing. And it does not allow to pass such an array as an argument.

One conceptual observation.

Variables that are children of "VARIABLE" are passed to other words by
reference — the address that contains the assigned data object is
passed. Thus, the callee can assign another data object to the passed
variable (from a conceptual point of view).

But variables that are children of "VALUE" are only passed by value —
the assigned data object is passed by itself. So the callee *cannot*
assign another data object to the passed variable ("variable is passed"
from a conceptual point of view, actually the assigned data object is
passed via the stack).

Of course, for a static VALUE-flavored variable, a definition to
reassign the variable can be passed to the callee:
0 value foo
: bar ... [: to foo ;] baz ... ;

This means that there is no much sense in having many methods to operate
on a VALUE-flavored variable, since these methods cannot be used in the
callee, if these methods are not passed individually.

For comparison, for DEFER-flavored variable we have general methods
"DEFER@" and "DEFER!", so the callee can reassign such a variable.

Concerning other languages — it is believed that modern languages do not
provide a way that allows the callee to reassign a passed variable (so
the caller can detect that).

--
Ruvim

Stephen Pelc

2024-03-20 11:37:01 UTC

Post by Gerry Jackson
I think introducing an overloaded parsing word TO was a much bigger
mistake. Much simpler is eliminating TO by exploiting Forth's
: val create , ;
111 val a
: a! a ! ; \ Replaces TO a
: a+! a +! ; \ Replaces +TO 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

In VFX Forth (the Forth used by Nick) the definitions of TO and -> are
identical. See
the file kernel64.fth for the source code.

VFX Forth defines the operators such as TO and -> as immediate words that just
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.

Stephen

--
Stephen Pelc, ***@vfxforth.com
MicroProcessor Engineering, Ltd. - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)78 0390 3612, +34 649 662 974
http://www.mpeforth.com
MPE website
http://www.vfxforth.com/downloads/VfxCommunity/
downloads

Hans Bezemer

2024-03-20 13:19:19 UTC

Post by Stephen Pelc
VFX Forth defines the operators such as TO and -> as immediate words that just
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.

In 4tH, VALUE is considered to be a dereferenced VARIABLE. As you all
know, VARIABLE returns an address and ! and @ act on that address.

TO "knows" it has to act on a dereferenced VARIABLE - and has its own
opcode. VALUE has its own opcode too (with a "builtin" @).

4tH's optimizer does strength reduction in that regard. When compiling

VARIABLE a 10 a !

It actually compiles a "TO":

Addr| Opcode Operand
0| literal 10
1| to 0

Since the address of the VARIABLE is known at runtime. Same for fetching
the value of a VARIABLE - it is treated as a VALUE.

On the other hand, the extension +TO is expanded as an +! expression:

Addr| Opcode Operand

0| literal 10
1| to 0 ( 10 a !)
2| value 0 ( a @)
3| literal 20
4| to 1 ( 20 value b)
5| literal 10
6| variable 1
7| +! 0 ( 10 +to b)

In short - in 4tH there is hardly any difference between VALUE and
VARIABLE. They can be used interchangeably. The actual code that is
generated is decided under the hood.

Hans Bezemer

dxf

2024-03-20 03:07:47 UTC

Post by dxf
...
Unlike Bartholdi's VARIABLE, Tracy's new data type had aspects more
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.

In my case this was easiest to implement and folks have come to expect
VALUEs are pre-initialized.

But, "VALUE" does not imply a new *data type*, but only a new type/subtype of named Forth definitions, if you like.

Yes - technically it's a variable that's been assigned a value.

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...

dxf

2024-03-20 09:37:39 UTC

Post by dxf
...
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.

Googling brought up these:

INTEGER (FD-V6N2)
INTEGER: (QED-FORTH)

Interestingly neither take a parameter. Likely I'll go with INTEGER .
VALUE will be deprecated.

Anton Ertl

2024-03-19 17:21:57 UTC

Post by dxf
https://pastebin.com/p5P5EVTm

...

Post by dxf
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.

Post by dxf
Unlike Bartholdi's VARIABLE, Tracy's new data type had aspects more
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 !

- anton

dxf

2024-03-20 03:10:28 UTC

Post by dxf
https://pastebin.com/p5P5EVTm

...

Post by dxf
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.

Post by dxf
Unlike Bartholdi's VARIABLE, Tracy's new data type had aspects more
n VALUE name

That's very sensible, and fig-Forth also supplied an initial value to
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 !

What do you do when your application restarts? The values assigned at
creation-time have likely changed.

Anton Ertl

2024-03-20 07:47:34 UTC

Post by Anton Ertl
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.

For settings where the application is restarted without reloading it,
an approach like the Unix data segment might be a good way: Have the
data space for all the variables collected in a compact memory block,
and, upon restart, copy the initial value from a memory block of
initial values (possibly in Flash or on disk). This has the following
advantages:

1) Better source code:

a) The initial value is obvious with the variable, and not somewhere
else.

b) The programmer cannot forget to (re-)initialize a variable.

2) More efficient in both space and time:

a) Instead of having an initializing word with lots of stuff like

5 v1 !
bl v2 c!

etc., only a MOVE or READFILE is needed, saving space; yes, you
need the memory block with the initial data, but you also need the
initial data in this initializing word, which will therefore be
longer than the initial data.

b) Block copy tends to be faster in modern CPUs than doing the same
thing with single-cell (or, worse, single-char) stores.

As a refinement of this approach, variables initialized to 0 can be
stored in another section that is just ERASEd, no need to keep the
initial value of these variables around and to copy them (in Unix this
is the bss segment).

Of course this approach would require a way for the Forth system to
know the initial values of variables. Unfortunately, the convenient
way to do this by providing the initial value to VARIABLE has not been
standardized, and no other way has been standardized, either. But for
VALUE, one can take this approach.

- anton

a***@spenarnc.xs4all.nl

2024-03-20 12:49:35 UTC

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.

With ample memory it is not worthwhile to restart the Forth system.
The application was tested, ignore the "isn't unique message".

With ciforth making executables is easy. This alternative allows to
pass parameters to the executable.

<SNIP>

Post by Anton Ertl
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html

Groetjes Albert

Anton Ertl

2024-03-21 07:52:09 UTC

Post by a***@spenarnc.xs4all.nl

Post by Anton Ertl
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.

Post by a***@spenarnc.xs4all.nl
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.

Post by a***@spenarnc.xs4all.nl
This alternative allows to
pass parameters to the executable.

In Gforth you can pass parameters in two ways:

My preferred way is to pass them before loading the program, e.g., with

gforth -e "100 constant somesize" program.fs

The advantage of this method is that there is no need for special
argument-accessing code in program.fs; however, you may want to
provide a default for SOMESIZE with

[undefined] somesize [if] 50 constant somesize [then]

The disadvantage of this method is that the invocation of the program
does not look like that of a classic Unix executable. So if you want
to invoke program without explicitly mentioning gforth, you need to
use NEXT-ARG (or some of the other non-standard words described in
<https://gforth.org/manual/OS-command-line-arguments.html#index-next_002darg>).

Here's an example:

[/tmp:147807] cat <<EOF >example

Post by a***@spenarnc.xs4all.nl
#! /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

a***@spenarnc.xs4all.nl

2024-03-21 10:30:46 UTC

Post by a***@spenarnc.xs4all.nl

Post by Anton Ertl
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.

Merely inconvenient.

Post by a***@spenarnc.xs4all.nl
With ciforth making executables is easy.

Easy is still harder than doing nothing.

It is so easy that it pays off not loading the source several times,
even with command repeaters like rlwrap.
The situation is that you want to run programs with different parameters,
e.g. projecteuler.net with increasing sizes, the last one several hours.
Reloading the source is just a waste of time, but more importantly
a distraction.
$EDITOR aap.frt
..
make aap

With a line in the Makefile
%: %.frt ; $(FORTH) -c $<

Post by Anton Ertl
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.

<SNIP>

Post by Anton Ertl
[/tmp:147807] cat <<EOF >example

Post by a***@spenarnc.xs4all.nl
#! /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.

Here is the take on this with ciforth
----------------------------
#!/usr/bin/lina -s

BEGIN ARGC 1 > WHILE 1 ARG[] TYPE SPACE SHIFT-ARGS REPEAT
CR
----------------------------
~/PROJECT/ciforths/ciforth: script a b c d
a b c d

- You specify with -s that you run a script
- No space after #! , that is a pitfall.
- in scripting you want to run interpretive control structures
more than normal
- Of course you must chmod.

Options are convenient, because Forth has many faces,
interactive trying, scripting, compilation, debugging, developing,
ease of use at the cost of occasional failure.
none : bald interpreter
-a : library attached
-c : compile
-s : script
-n : newbie, autoload from library
-e : electives, development tools
Read once through the applicable chapter and you at least
remember how to do things. Option -s is not hard to
associate with scripts.

Post by Anton Ertl
- anton

Groetjes Albert

mhx

2024-03-20 08:09:05 UTC

dxf wrote:

[..]

Post by dxf
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).

I solve now this by adding variables and values (and generated code) to
a list of 'must-initialize' candidates and explicitly executing a word
to do that at 'boot time.' There are complications with parallel
programming where only a 'section master' should be able to reset
the list (in shared memory), or where the list contains values to be
set/computed depending on the ID of a computing node. (Some nodes are
only allowed to read, some to read/write). There are quite a few
peculiarities and possible bugs here.

One 'solution' is to always reboot and never restart, but then everything
has to be computed anew when trivially editing the program (or using a
different netlist). Read/write to disk depends on 'circumstances' and
does not really make this easier ('What are all these files your/my
program generates, can I delete/move/edit them?').

-marcel

minforth

2024-03-20 09:03:28 UTC

Post by mhx
[..]

Post by dxf
What do you do when your application restarts? The values assigned at
creation-time have likely changed.

In PLCs, where programs are usually processed cyclically, there are often
two methods for initialisation:
1) Constant initialisation of variables etc. in RAM is carried out by
automatically called init-methods for each function block.
2) A configurable start sequence (so-called cycle 0) takes care of the rest,
e.g. to perform calculations whose result then provides an initialisation
value (e.g. for counters or integrators).

In simple applications, the start sequence is often empty or only short,
as the init-methods are usually sufficient. The initialisable function blocks
are chained together for this purpose. At system startup, the chain is
processed automatically without requiring any additional programming effort.

Transferring this concept to Forth, I would use chained VALUEs as data objects.
I already have three methods per VALUE (as already described elsewhere),
adding a fourth init-method would be linear and easy.

FFmike

2024-03-24 17:02:36 UTC

Post by dxf
What do you do when your application restarts? The values assigned at
creation-time have likely changed.

In FlashForth this is handled elegantly by having data sections for flash, eeprom and ram.
Any changed data in flash or eeprom is there after a restart.

This works if the data is of semi-static nature like calibration constants.
Otherwise you have to copy the data to ram at startup. And write it to eeprom also if the values in ram contents needs to survive a restart.

Dictionary pointers are cached in ram, and only stored to eeprom if they are modified. But these are special cases to make the compiler run faster and save eeprom from wearing.

Ruvim

2024-03-25 20:10:02 UTC

Post by dxf
https://pastebin.com/p5P5EVTm

...

Post by dxf
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.

Post by dxf
Unlike Bartholdi's VARIABLE, Tracy's new data type had aspects more
n VALUE 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 !
;

which allows to write

n in-var name

instead of

variable name n name !

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".

--
Ruvim

dxf

2024-03-26 02:05:09 UTC

Post by dxf
https://pastebin.com/p5P5EVTm

...

Post by dxf
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.

Post by dxf
Unlike Bartholdi's VARIABLE, Tracy's new data type had aspects more
n VALUE name

And most likely n is 0, isn't it? Therefore, a requirement to systems to initialize variables by zero simplifies programs.

Forth-79 made applications responsible for initializing variables if that
be needed. Is this now being challenged?

Anton Ertl

2024-03-26 08:02:26 UTC

And most likely n is 0, isn't it?

What makes you think so? See the VALUE results below.

Post by Ruvim
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?

Post by Ruvim
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.

Post by Ruvim
To define a variable with an explicitly specified initial value, why not
: 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.

Post by Ruvim
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.

Post by Ruvim
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

minforth

2024-03-26 12:24:11 UTC

Post by Anton Ertl
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.

Ruvim

2024-03-26 13:35:34 UTC

Post by minforth

Here DEFERs default to NOP, like VARIABLEs to 0. Never had an issue with this.

A safer option is to throw an exception.

--
Ruvim

dxf

2024-03-26 13:48:48 UTC

Post by minforth

Here DEFERs default to NOP, like VARIABLEs to 0. Never had an issue with this.

DEFER is another word most would have picked up from F83. The default
action was:

: CRASH (S -- )
TRUE ABORT" Uninitialized execution vector." ;

Seems like something that should have had a standard THROW code.

Ruvim

2024-03-26 13:34:14 UTC

And most likely n is 0, isn't it?

What makes you think so? See the VALUE results below.

I applied grep to Gforth and other source codes to find the pattern
"VARIABLE name n name !", and evaluated the statistics. Among all
initial values for "VARIABLE", zero is used much more often than any
other value.

The command:

ag -G '\.(f|fs|fth)$' --no-filename -o -i \
'variable (\S+)\s+(\S+)\s+(\1)\s+!' \
| grep -P -o '((?<=\s)|^)\S+(?=\s+\S+\s+!)' \
| sort --ignore-case -r | uniq --ignore-case -c | sort -n -r | less

The results for Gforth sources:

91 0
6 -1
3 1
2 here
2 80
2 -20
2 -2
2 -100
1 string_buf
1 Names
1 FALSE
1 6
1 -2048
1 -10753
1 $1234
1 $10
1 #24

Post by Ruvim
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

No, I compare "VARIABLE name 0 name !" and "VARIABLE name".
What I mean is that if the children of "VARIABLE" will be initialized to
zero (by default), then cases of the first pattern will become cases of
the second pattern. This simplifies programs. Also, it's backwards
compatible (i.e., old programs will work correctly on new systems).

Post by Anton Ertl
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.

Not necessary. In some cases, a variable is a part of a static object in
the program, and all parts of that object are initialized by a separate
word, and this word is called on every loop. So, there is no sense to
initialize each variable separately on creation.

Post by Anton Ertl
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?

Of course I agree that
0 fig-variable foo
is simpler than
variable foo 0 foo !

But this variant
var foo
(which initializes "foo" to zero), is even more simple.

As I see now, majority programs in SP-Forth rely on "VARIABLE"
initializing a variable with zero (a system-specific behavior).

Post by Ruvim
If an uninitialized variable is required by a program, it can be defined
using "BUFFER:".

I consider some use cases that are not covered by the standard, for
example, target compilation for a very limited environment.
Uninitialized variables will not take memory in ROM and CPU for erasing.

And even if the standard will require "VARIABLE" to initialize the new
variable to zero, a user still has a mean to define a variable that
*may* have a random initial value.

Post by Anton Ertl
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:.

Yes, sure!

Post by Anton Ertl
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.

Post by Ruvim
To define a variable with an explicitly specified initial value, why not
: in-var ( n "name" -- )
variable
latest-name name> execute !
;

: in-var ( n "name" -- )
create , ;

Yes, but probably less efficient.
In my definition I also show the usefulness for the proposed word
"latest-name" ;)

Post by Anton Ertl
Yes, such a word is a good idea, although I would use a different name.

Post by Ruvim
Another observation. "DEFER" (which is similar to "VALUE") does not
accept an initial value. Well, in most use cases this value yet unknown.

Agree. In my implementation the initial value throws an exception.
I think, the throw code should be specified in the standard to eliminate
the corresponding ambiguous condition.