From: ruvim.pinka@gmail.com
On 2024-03-26 08:02 +00, Anton Ertl wrote:
> Ruvim 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
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
