In article <utbptf$peiu$1@dont-email.me>, Ruvim <ruvim.pinka@gmail.com> wrote: >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 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.

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 -

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 19/03/2024 10:37, Ruvim wrote:

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.

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.

[...]

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

--
Gerry

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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 !

- 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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Gerry Jackson <do-not-use@swldwa.uk> writes:

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

...

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

mhx wrote:

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

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 19 Mar 2024 at 15:42:24 CET, "Gerry Jackson" <do-not-use@swldwa.uk> wrote:

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

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, stephen@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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <2024Mar20.084734@mips.complang.tuwien.ac.at>,
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:

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.

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>

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

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 -

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <ccaf20ae25dc1b31723baffc72ee8ef1@www.novabbs.com>,
minforth <minforth@gmx.net> wrote:

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:

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

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

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 -

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

albert@spenarnc.xs4all.nl wrote:

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)