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. In a survey of my usage of VALUE I have
indeed used VALUE where a CONSTANT should have properly been used.
This was only discovered when I set about to investigate what would
be the impact of my omitting the numeric prefix at creation.

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

--
Ruvim

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 -

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

On 2024-03-19 18:38, albert@spenarnc.xs4all.nl wrote:
> 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.

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

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

On 2024-03-19 18:42, Gerry Jackson wrote:
> 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.

Why do you think it's a 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"

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

> 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

On 19/03/2024 9:37 pm, Ruvim 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.

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.

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

On 20/03/2024 4:21 am, 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 !

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

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

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

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.

On 20/03/2024 2:07 pm, dxf wrote:
> 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...

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.

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

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 -

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 -

On 20-03-2024 12:37, Stephen Pelc wrote:
> 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

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.

On 21/03/2024 6:00 am, minforth wrote:
> ...
> Nobody needs VALUEs that only conceal a few @s

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.

albert@spenarnc.xs4all.nl writes:
>>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.

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

>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
> #! /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
--
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

In article <2024Mar21.085209@mips.complang.tuwien.ac.at>,
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>albert@spenarnc.xs4all.nl writes:
>>>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.

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

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

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

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 -

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

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.

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