Here is a very simple RfD --- I'm not pushing for quotations or any other such thing that realistically will never be accepted in Forth-200x. This one just fixes one of the more glaring failures of ANS-Forth. For the most part, I have lost interest in Forth-200x. This RfD will fix a problem that is causing my code to be horribly cumbersome and hard-to-read though, and it is a super-simple solution, so I'll post it.

Author

-------

Hugh Aguilar

Problem

---------

The program, given an address returned by ALLOCATE or RESIZE, has no way of finding out how big that chunk of memory is.

Current Practice

-----------------

When the programmer calls ALLOCATE or RESIZE, he keeps track of the size somewhere in his own program.

As an example, In my LIST.4TH software (http://www.forth.org/novice.html), each node has a .NODE-SIZE field that keeps track of the node's size. This is necessary because the lists often contain a variety of data types, all derived from LIST, but all different sizes.

My .NODE-SIZE field is a waste of memory. This information is held internally (FREE and RESIZE are able to obtain it), so there is no need for me to hold onto it as well.

The worst problem though, is that constructors are more complicated. Each constructor calls the parent constructor first, and then does its own initialization of fields. The problem though, is that the .NODE-SIZE field ends up getting initialized repeatedly in the chain of constructors, and smaller every time --- so it is wrong. The solution is to call INIT-LIST with the correct size after having called the parent constructor. This is fixes the .NODE-SIZE field. It is a waste of time to do this though. This is also confusing because the programmers don't do this in other languages such as C++. It seems unnecessary and confusing to them. Also, if they forget, they don't find out about the problem until and if they use CLONE-NODE at some time in the future. There is a huge possibility here for a bug that most programmers would find difficult to track down. I've actually been bitten by this bug so many times now that I'm pretty alert to it, but most programmers would not expect this and would be confused.

Solution

--------

The solution is to provide a word SIZE that returns the size of a heap allocation, given the address of that heap allocation (the address returned by ALLOCATE or FREE).

Proposal

---------

Introduce a new word:  SIZE ( adr -- size )

This would be in the optional Memory-Allocation word set (chapter 14).