Loading ...
Sorry, an error occurred while loading the content.
 

SIZE RfD

Expand Messages
  • Hugh Aguilar
    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
    Message 1 of 49 , Jan 29, 2010
      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).


    • BruceMcF
      Hugh Aguilar , Tue, Feb 9, 2010 3:24 pm ... that ... ... that is, storing it in each instance of each type of node rather than in a
      Message 49 of 49 , Feb 9, 2010
        Hugh Aguilar <hughaguilar96@...>, Tue, Feb 9, 2010 3:24 pm

        > The RfD discussed *nothing other* than the implementation of multiple
        > 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
        that
        > CLONE-NODE would know how much data to copy. This is a huge waste
        > of memory however,

        ... that is, storing it in each instance of each type of node rather
        than in
        a single descriptor of all node type information that each node points
        to?

        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
        function
        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-memory
        > computers.

        And 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,
        > is that .NODE-SIZE keeps getting reset to ever smaller values as the
        > constructors call their parent constructors.

        This sounds like a broken design.

        > The solution is to reset .NODE-SIZE correctly with INIT-LIST after
        > calling the parent constructor, which fixes all of the incorrect
        setting
        > 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 just
        pointing
        > out that Forth is 1970's retro. Problems such knowing how big a node
        > is, were solved by everybody else in the world during the 1980s.

        You are not proposing a general solution to that problem, you are
        proposing a standardization of a different function that would be
        used to address that problem for a particular implementation
        strategy.

        > Problems such as CREATE DOES> allowing only *one* action
        > to be associated with an object, are also pretty mind-boggling to
        > anybody who is too young to have done any pre-1990 programming.

        Note that this claim is empirically false, since its common knowledge
        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 to
        not
        > 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 job
        > 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.

        The purpose of the Forth 200x process should *not* be marketing
        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.

        Bruce McFarling
        Ravenna, Ohio
      Your message has been successfully submitted and would be delivered to recipients shortly.