Paul Rubin wrote:

> albert@spenarnc.xs4all.nl writes:
>> Algol68 doesn't crash. It gives a run time error of the type

> Well that's what I mean by crashing. The program is terminated
> "involuntarily", or alternatively there is some way to catch the exception.
> Either way, the computation doesn't proceed.

>> You can't get much help from the compiler for uninitialised references
>> like this. Either it crashes in the first run or it is insidious.

> No idea about Algol68 but in (at least some) other languages, the idea
> of having references instead of pointers is that it is impossible to
> create an uninitialised reference.

In Forth parlance: unless you're doing system programming where you need it,
don't use direct memory operations like @ ! MOVE, etc. This also prohibits
the use of VARIABLE. VARIABLES are uninitialized and are accessed by @ !.

So I regularly use either xVALUEs (x means different data types) or data
objects (for compound or dynamic types) with access methods. This results
in cleaner code and improves memory safety.

minforth@gmx.net (minforth) writes:
> In Forth parlance: unless you're doing system programming where you
> need it, don't use direct memory operations like @ ! MOVE, etc. This
> also prohibits the use of VARIABLE. VARIABLES are uninitialized and
> are accessed by @ !.

That helps but I'm sure there are other hazards. What do you do about
arrays? What about ALLOT or ALLOCATE?

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

> So I regularly use either xVALUEs (x means different data types) or data
> objects (for compound or dynamic types) with access methods. This results
> in cleaner code and improves memory safety.

Yes I should start doing that too. I only mess with Forth for fun
though. I feel like it helps me stay sharp compared with safer
languages, even including C. I'm not old enough to have written
significant amounts of machine code.

Paul Rubin wrote:

> minforth@gmx.net (minforth) writes:
>> In Forth parlance: unless you're doing system programming where you
>> need it, don't use direct memory operations like @ ! MOVE, etc. This
>> also prohibits the use of VARIABLE. VARIABLES are uninitialized and
>> are accessed by @ !.

> That helps but I'm sure there are other hazards. What do you do about
> arrays?

Arrays are heap-allocated dynamic objects with access methods. Direct memory
access is virtually impossible (but with "carnal knowledge"). There
is an array stack for more complex operations and a chain of array values
for persistent storage. Stack and array values contain only pointers.

F.ex.
XZ14[ designates array (matrix or vector) value XZ14
<index or indices> ] reads a vector/matrix element
<index or indices> ]! writes to a vector/matrix element
M"[ 2 1 ] from 3rd array on array stack read 1st element in 2nd row
(M[ M'[ M"[ designate top, second and third matrix on array stack)
XZ14[ ]' pushes transposed matrix XZ14 onto array stack
=> XZ14 (or TO XZ14) writes top matrix to array value XZ14
et cetera

IOW there is a special word set for array operations. Operators check
that there is no memory violation like index out of bounds, and do some
housekeeping like (re)allocating memory.

> What about ALLOT or ALLOCATE?

Above word set would be overkill for normal Forth applications.
Nevertheless you could SEAL your search order and exclude or make
safer versions of ALLOT et al for your application wordlist.
I never understood why SEAL did not make it into ANS Forth's
Search-Order word set, as it is just a simple SET-ORDER thing.

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

Yes and no. It is easy to forget correct initialization when 0 is wrong.
VALUEs explicitly require conscious initialization.

On 16/03/2024 5:37 am, Paul Rubin wrote:
> minforth@gmx.net (minforth) writes:
>> In Forth parlance: unless you're doing system programming where you
>> need it, don't use direct memory operations like @ ! MOVE, etc. This
>> also prohibits the use of VARIABLE. VARIABLES are uninitialized and
>> are accessed by @ !.
>
> That helps but I'm sure there are other hazards. What do you do about
> arrays? What about ALLOT or ALLOCATE?
>
> At least in gforth, VARIABLEs are initialized to 0. That seems like a
> good thing for implementations to do ingeneral.
>
>> So I regularly use either xVALUEs (x means different data types) or data
>> objects (for compound or dynamic types) with access methods. This results
>> in cleaner code and improves memory safety.
>
> Yes I should start doing that too. I only mess with Forth for fun
> though. I feel like it helps me stay sharp compared with safer
> languages, even including C. I'm not old enough to have written
> significant amounts of machine code.

In early forths (microFORTH, figFORTH) one was required to supply an
initial value:

0 VARIABLE name

Nowadays one can write:

VARIABLE name 0 name !

or as I do:

\ Set application defaults
: DEFAULTS ( -- )
0 to outdev shaping off spacing off
train on koch off
plain-text punct off compress on ignore off
7 send.s ! 15 char.s ! 3 cspace ! 7 wspace !
700 tone ! 7 volume ! sqr1wave
6 groupcols ! 4 grouprows ! 3 groupsize !
lsignal off 0 to hide ;

defaults

With one word I initialize everything in the application that deserves it.
That leaves VALUEs which are needlessly initialized twice. If it was
deemed poor practice to initialize VARIABLEs at creation, the same applies
to VALUEs.

On 16/03/2024 5:37 am, Paul Rubin wrote:
> minforth@gmx.net (minforth) writes:
>> In Forth parlance: unless you're doing system programming where you
>> need it, don't use direct memory operations like @ ! MOVE, etc. This
>> also prohibits the use of VARIABLE. VARIABLES are uninitialized and
>> are accessed by @ !.
>
> That helps but I'm sure there are other hazards. What do you do about
> arrays? What about ALLOT or ALLOCATE?
>
> 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.

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

Indeed, if you only work with integers in cell size, VARIABLEs and some
code discipline are sufficient.

VALUEs are like variants in VBA. You can only change them with TO <NAME>,
and TO (alias =>) is the same for all data types. The standard also writes
locals and FVALUEs with TO. Non-standard $VALUEs (for dynamic strings) or
DVALUEs/ZVALUEs can be very practical too. I also use range-limited VALUEs.
None of this works with VARIABLEs.

When you implement your type-specific TO variants with built-in
appropriate checking, you are on the safer side.

minforth@gmx.net (minforth) writes:
>Non-standard $VALUEs (for dynamic strings) or
>DVALUEs/ZVALUEs can be very practical too.

2VALUE is standard.

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

> minforth@gmx.net (minforth) writes:
>>Non-standard $VALUEs (for dynamic strings) or
>>DVALUEs/ZVALUEs can be very practical too.

> 2VALUE is standard.

2VALUEs are for cell pairs. DVALUEs do not exist, because
the standard assumes equivalency of double numbers and cell
pairs (although mathematically they are not).
ZVALUEs are for complex numbers.

On 16/03/2024 8:35 pm, minforth wrote:
> dxf 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.
>
> Indeed, if you only work with integers in cell size, VARIABLEs and some
> code discipline are sufficient.
>
> VALUEs are like variants in VBA. You can only change them with TO <NAME>,
> and TO (alias =>) is the same for all data types. The standard also writes
> locals and FVALUEs with TO. Non-standard $VALUEs (for dynamic strings) or
> DVALUEs/ZVALUEs can be very practical too. I also use range-limited VALUEs.
> None of this works with VARIABLEs.
>
> When you implement your type-specific TO variants with built-in
> appropriate checking, you are on the safer side.

If safety is where one wants to be, there are surely better choices than
Forth. For myself, I'd have to agree with Paul:

"I only mess with Forth for fun though. I feel like it helps me stay
sharp compared with safer languages, even including C."

But VALUEs in Forth had little to do with safety. Its history, form,
issues and attempted solutions is summarized here:

https://pastebin.com/p5P5EVTm

(ref: "svars.arc" Taygeta Forth archive)

Interesting. I didn't know that the TO concept was coined by Moore (before Bartholdi).

-marcel

On 17/03/2024 6:30 pm, mhx wrote:
> Interesting. I didn't know that the TO concept was coined by Moore (before Bartholdi).
>
> -marcel

A momentary lapse by Moore? TO was an abstraction. 'Under the hood' it was still
addresses, @ and ! .

On 05/03/2024 14:03, minforth wrote:
> Tristan Wibberley wrote:
>

>> Or special purpose computers that are not mass marketed, but I wasn't
>> aware they'd fixed all the public market computers. Thanks for the info.
>
> You are still in for some nasty surprises with "public market" ARM CPUs.
> f.ex.
> https://developer.arm.com/documentation/den0013/d/Porting/Alignment

And then we're not even trying to talk about what's in use and for sale
today but rather what will be in use over the next 6 decades. Most of
the historical peculiarities that are eliminated with more complex
hardware instead of longer software can be expected to be present at
some point during that period because more complex hardware is already a
difficult problem for information security and I'd expect those
peculiarities wouldn't have been present if there weren't some
efficiency earned.

Tristan Wibberley wrote:

> On 05/03/2024 14:03, minforth wrote:
>> Tristan Wibberley wrote:
>>

>>> Or special purpose computers that are not mass marketed, but I wasn't
>>> aware they'd fixed all the public market computers. Thanks for the info.
>>
>> You are still in for some nasty surprises with "public market" ARM CPUs.
>> f.ex.
>> https://developer.arm.com/documentation/den0013/d/Porting/Alignment

> And then we're not even trying to talk about what's in use and for sale
> today but rather what will be in use over the next 6 decades. Most of
> the historical peculiarities that are eliminated with more complex
> hardware instead of longer software can be expected to be present at
> some point during that period because more complex hardware is already a
> difficult problem for information security and I'd expect those
> peculiarities wouldn't have been present if there weren't some
> efficiency earned.

Although repeatedly proclaimed dead, we can still observe Moore's Law.
With the increasing 3-dimensional design of CPUs and the hunger for massive
computing power through AI applications, the trend is likely to continue.
Another driver is the need for lower energy consumption.

This means that as the complexity of systems grows almost exponentially,
the consequences of software errors will become increasingly dangerous in
the same magnitude. Just as a professional electrician only works with
insulated tools, a professional programmer should also choose his tools,
e.g. programming languages, which do not allow even simple errors to occur
in the first place. They should also use operating systems and software
containers equipped with protective functions.

These means of protection that already exist today are not available in
archaic programming languages such as C or Forth. Stoic language
conservativism (a tenor in standard Forth) won't help.