On 26/03/2024 7:10 am, Ruvim wrote:
> 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.

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

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

Anton Ertl wrote:

> If the value is not yet known, the deferred word must not be called.
> So a good initialization value produces an exception. In Gforth it
> produces a warning for now, but after >15 years of warnings, it's time
> to actually produce an exception.

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

On 2024-03-26 08:02 +00, Anton Ertl wrote:
> 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.

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

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

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

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

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

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

> 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, but probably less efficient.
In my definition I also show the usefulness for the proposed word
"latest-name" ;)

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

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.

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

Yes. "most likely" means the case that has the highest probability among
all possible cases.

--
Ruvim

On 2024-03-26 16:24, minforth wrote:
> 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.

A safer option is to throw an exception.

--
Ruvim

On 26/03/2024 11:24 pm, minforth wrote:
> 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.

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.

On 2024-03-20 00:59, Ruvim wrote:
> On 2024-03-19 18:42, Gerry Jackson wrote:
>> On 19/03/2024 10:37, Ruvim wrote:
[...]
>>>
>>> Another name only can be introduced.
>>>
>>
>> I think introducing an overloaded parsing word TO was a much bigger
>> mistake.
>> Much simpler is eliminating TO by exploiting Forth's redefinition rules:
>>
>> : val create , ;
>> 111 val a
>> : a! a ! ;    \ Replaces TO a
>> : a+! a +! ;    \ Replaces +TO a
>> : a a @  ;    \ Hide the CREATEd a
>> a 222 a! a 99 a+! a ( -- 111 222 321 ) .s
>
> I prefer this way over "TO" too. In my implementation [1], the getter
> and setter are created automatically:
>
>   slot( a b )
>   111 222 set( a b )
>   a b + set-a  a .  \ "333"
>
>
[...]
>> Incidentally I'd like to see VALUEs extended much as described in N J
>> Nelson's papers in EuroForth 2020 and 2022
>>     http://www.euroforth.org/ef20/papers/nelson.pdf
>>     http://www.euroforth.org/ef22/papers/nelson-values.pdf
>> but that still uses a parsing operator -> instead of TO
>>
>
> I dislike "TO"-based approach/syntax for arrays and structures.
>
> This approach supposes, that the array "X" is actually a kind of
> fetching from index (like "@"):
>   X ( index -- data )
>
> And "TO X" is a kind of storing to index (like "!"):
>   TO X ( data index -- )
>
> It's confusing. And it does not allow to pass such an array as an argument.

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