- 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 AguilarProblem---------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).
- Hugh Aguilar <hughaguilar96@...>, Tue, Feb 9, 2010 3:24 pm
> The RfD discussed *nothing other* than the implementation of multiplethat
> data types in a linked list.
> In my LIST.4TH program I had to provide each node with a .NODE-SIZE
> field that keeps track of how big the node is. This was necessary so
> CLONE-NODE would know how much data to copy. This is a huge waste... that is, storing it in each instance of each type of node rather
> of memory however,
a single descriptor of all node type information that each node points
Note that the original function requested was the amount of memory
originally requested from ALLOCATE, which requires in the general
case for the exact same information to be stored with each request
to ALLOCATE memory, when only some instances of the allocated
memory *require* that information.
(In later discussion, you stated that you had not objection to the
returning the actual ALLOCATION of memory, instead, which would
reduce the memory impact when ALLOCATION size information can
be directly inferred by accessing the implementation-or-system
dependent heap allocation information.)
> and this can become a serious problem in small-memoryAnd this (the actual request when the memory was ALLOCATEd)
can become a serious problem in small-memory computers,
especially if using applications with profligate calls to ALLOCATE.
> Also, a problem with setting .NODE-SIZE in the constructor however,This sounds like a broken design.
> is that .NODE-SIZE keeps getting reset to ever smaller values as the
> constructors call their parent constructors.
> The solution is to reset .NODE-SIZE correctly with INIT-LIST aftersetting
> calling the parent constructor, which fixes all of the incorrect
> of .NODE-SIZE that has been going on. This is a gross kludge.Broken designs often lead to later gross kludges.
> It is not my intention to insult anybody's intelligence. I am justpointing
> out that Forth is 1970's retro. Problems such knowing how big a nodeYou are not proposing a general solution to that problem, you are
> is, were solved by everybody else in the world during the 1980s.
proposing a standardization of a different function that would be
used to address that problem for a particular implementation
> Problems such as CREATE DOES> allowing only *one* actionNote that this claim is empirically false, since its common knowledge
> to be associated with an object, are also pretty mind-boggling to
> anybody who is too young to have done any pre-1990 programming.
that multiple object oriented systems have been implemented with
CREATE DOES> that each allow multiple actions to be associated
with the object.
> It is an insult to *my* intelligence that I should be expected tonot
> notice how retro the ANS-Forth standard is.This is a false dichotomy. Forth-94 can be a retro standard without
your proposal being worthy of support.
> I can't seriously mention my Forth work-experience in a jobThe purpose of the Forth 200x process should *not* be marketing
> interview for a programming position because doing so makes
> the interviewers think that I don't know anything about OOP and
> would not be capable of programming in a modern language.
focused on responding to stereotypes of Forth. It should be to
make it easier to write portable libraries of Forth source that can
be run on multiple implementations. There is ample work to be
done there without tackling status distinctions.
And in any event, its not feasible for a standardization process
*to* directly address that perceived social status inferiority among
programmers. All that standardization can do is to remove
roadblocks to problem solutions. Its only the problem solutions
themselves that might address that perceived social status
inferiority - probably won't, but might.