Array futures

Arrays as they stand now, are ref-counted objects. Whilst is fine for most instances, if I want to move this toy 'Forth' implementation towards compilation, static-sized arrays held inside words are necessary.

The issue is the user-defined words - the system used to define words needs to be created in Forth, not C++. To hold the definition in a word, an array needs to be created within the word, holding a type and a default value.

The issue is that a word contains an array of WordBodyElement* - it is defined as a (C-style) array of type WordBodyElement**. However, the whole system when asking a StackElement for its contained WordBodyElement (which might contain an integer as part of a word-based variable, or a float, or an object) expects a WordBodyElement*, not a point that references the (C-Style) array as a whole.

This makes it impossible to access other elements of the array.

For instance, if a WORD-based variable contains 3 WordBodyElement* inside an array, and its first word (CFA) is PushPter, it will push a pointer on the stack holding a WordBodyElement*, a pointer to the first element.

From this pointer it is impossible to move to the next (or previous) array element. For this to happen, the stack element would need to hold a WordBodyElement**.

Altering the code to do this is fairly monumental, due to storing the pointer a void* - which is done because we could be storing any pointer, with any indirection level. The point itself is useless without the corresponding ForthType which determines the indirection level as well as the ultimate value/object type.

Two routes are:

• Rewrite type system
• Come up with a series of tests involving all possible objects/values and indection levels, change the StackElements to return WordBodyElement**, and run the tests and fix the bugs.

I went for option 2. Not my finest coding moment.

With a change to the binary operations in ForthWord::BuiltInHelper_BinaryOperation to allow integer addition/subtraction on pointers, static arrays are now possible.

Outstanding bugs

An array containing objects instead of value types, may cause issues. A new array, having a value pushed into any element past the first, will try to decrement the reference count on a non-existent pter. This pter will either be a C++ nullptr, which is bad, or uninitialised memory, which is even worse.

To fix this, the elements need all setting to nullptr, and the method StackElement::PokeObjectIntoContainedPter updating to take this into account (it already does take null into account, but it needs testing).