wsbusup4@rw5.urc.tue.nl (Jan Stout) (05/06/91)
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