Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!crdgw1!uunet!mcsun!hp4nl!tuegate.tue.nl!rc6.urc.tue.nl!rw5.urc.tue.nl
From: wsbusup4@rw5.urc.tue.nl (Jan Stout)
Newsgroups: comp.lang.forth
Subject: DOES>
Message-ID: <585@rc6.urc.tue.nl>
Date: 6 May 91 10:34:37 GMT
Sender: news@rc6.urc.tue.nl
Organization: Eindhoven University of Technology, The Netherlands
Lines: 67

I've encountered some problems with DOES> as I was trying to implement
a vocabulary structure.
Because I think there is something essentially wrong with DOES>,
I've already put together a draft proposal.
I'd be glad to receive any critizism or comments.

Jan Stout, wsbusup4@urc.tue.nl

                FST Proposal and Comment Submittal Form
------------------------------------------------------------------------
FST USE     Title:                                 Proposal Number:
 ONLY -->   Related Proposals:                     Disposition:
========================================================================
Keyword(s): Defining Words, data field                     Category:
            address vs execution token     (*) Proposal  or  ( ) Comment
Forth Word(s): CREATE DOES>                Section #(s):
------------------------------------------------------------------------
Abstract:

DOES>'s use of the data field address is inflexible.



------------------------------------------------------------------------
Proposal and Discussion:

   Proposal:   Add the word DOES to the Core Extensions Word Set.
      DOES will be semantically equivalent to DOES>, except it will
      place the execution token of the word to be defined on stack,
      instead of it's data field address as DOES> does.

   Discussion: Use of the data field address as a word identifier has
      serious drawbacks in systems where the dictionary is implemented
      as a heap structure, instead of ar straightforward linked list.
      In these implementations a data field address is likely  to change
      due to the garbage collection associated with this flexible type
      of memory management.
      In fact the only address that is guaranteed not to change, is the
      execution token. Conseqently only the execution token is suited
      for word identification.
      Of course CONSTANTs which only use the word identifier
      temporarily, will not suffer from a possible change of their
      data field address after their compilation.
      Except for situations where the data field address is stored for
      later use in e.g. another VARIABLE, the same holds for CREATEd
      words and VARIABLEs.
      The next defining word that comes to mind however, i.e. WORDLIST
      cannot easily be implemented on the above mentioned systems when
      the only available construct is CREATE DOES>. Indeed using the
      data field address as `wid' (word list identifier) creates the
      very problem outlined in this discussion.

      Accidently, by calling the function DOES as proposed, the > that
      slipped in DOES> for historical reasons, will be indicative of the
      >BODY implicit in the DOES> word.

      Finally note that DOES> can easily be implemented using DOES:

      : DOES>   POSTPONE DOES   POSTPONE >BODY ; IMMEDIATE



------------------------------------------------------------------------
Submitted by: Jan Stout                           Date:  6 May 1991
              wsbusup4@urc.tue.nl                          Page  1 of  1
========================================================================
FORTH Standards Team;  PO Box 4545;  Mountain View, CA 94040      910506