595 lines
15 KiB
Plaintext
595 lines
15 KiB
Plaintext
|
|
|
|
|
|
|
|
C. EXPERIMENTAL PROPOSALS
|
|
|
|
|
|
|
|
|
|
APPENDIX C. EXPERIMENTAL PROPOSALS
|
|
|
|
|
|
Since FORTH is an extensible language and subject to evolution,
|
|
the Standard contains a section describing experimental
|
|
proposals. FORTH users are encouraged to study, implement, and
|
|
try these proposals to aid in the analysis of and the decision
|
|
for or against future adoption into the Standard. Readers are
|
|
cautioned that these proposals contain opinions and conclusions
|
|
of the authors of the proposals and that these proposals may
|
|
contain non-standard source code.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
65
|
|
|
|
|
|
|
|
|
|
|
|
C. EXPERIMENTAL PROPOSALS
|
|
|
|
|
|
|
|
|
|
|
|
|
|
SEARCH ORDER SPECIFICATION AND CONTROL
|
|
|
|
|
|
WILLIAM F. RAGSDALE
|
|
|
|
|
|
1 INTRODUCTION
|
|
|
|
The method of selecting the order in which the dictionary is
|
|
searched has grown from unchained vocabularies to the present use
|
|
of chained vocabularies. Many techniques are in use for
|
|
specification of the sequence in which multiple vocabularies may
|
|
be searched. In order to offer generality and yet get precision
|
|
in specification, this proposal is offered.
|
|
|
|
|
|
2 DESCRIPTION
|
|
|
|
The following functions are required:
|
|
|
|
1. Two search orders exist. CONTEXT is the group of
|
|
vocabularies searched during interpretation of text from the
|
|
input stream. CURRENT is the single vocabulary into which
|
|
new definitions are compiled, and from which FORGET
|
|
operates.
|
|
|
|
2. Empty CONTEXT to a minimum number of system words. These
|
|
are just the words to further specify the search order.
|
|
|
|
3. Add individual vocabularies into CONTEXT. The most recently
|
|
added is searched first.
|
|
|
|
4. Specify which single vocabulary will become CURRENT.
|
|
|
|
The following optional functions aid the user:
|
|
|
|
1. Display the word names of the first vocabulary in the
|
|
CONTEXT search order.
|
|
|
|
2. Display the vocabulary names comprising CURRENT and CONTEXT
|
|
search orders.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
66
|
|
|
|
|
|
|
|
|
|
|
|
C. EXPERIMENTAL PROPOSALS
|
|
|
|
|
|
3 ADVANTAGES
|
|
|
|
Use over the past year has demonstrated that the proposed
|
|
methods may emulate the vocabulary selection of all other
|
|
systems. The order is explicit by execution, may be interpreted
|
|
and compiled, and is obvious from the declaration. The search
|
|
order is specified at run-time rather than the time a new
|
|
vocabulary is created.
|
|
|
|
|
|
4 DISADVANTAGES
|
|
|
|
By migrating to a common structure, vendors give up one
|
|
point at which they may claim their product is better than
|
|
others. Another drawback is that the number of CONTEXT
|
|
vocabularies is fixed; older methods had an indefinite 'tree'
|
|
structure. In practice, the branching of such a structure was
|
|
very rarely greater than four.
|
|
|
|
Forth words operate in a context sensitive environment, as
|
|
word names may be redefined and have different definitions in
|
|
different vocabularies. This proposal compounds the problem. By
|
|
displaying the search order names, the user at least can readily
|
|
verify the search order.
|
|
|
|
|
|
5 IMPACT
|
|
|
|
The text of the Forth 83 Standard has been carefully chosen
|
|
for consistency and generality. However, no specification on how
|
|
the search order is developed by the user is given. This
|
|
omission is unavoidable, due to the diversity of contemporary
|
|
practice. This proposal is intended to complete the Forth 83
|
|
requirements in a fashion that exceeds all other methods.
|
|
|
|
Previously standardized words continue in their use:
|
|
VOCABULARY, FORTH, DEFINITIONS, and FORGET. However, this
|
|
proposal assumes that vocabulary names are not IMMEDIATE .
|
|
|
|
|
|
6 DEFINITIONS
|
|
|
|
Search order:
|
|
The sequence in which vocabularies are selected when
|
|
locating a word by name in the dictionary. Consists of one
|
|
transient and up to three resident vocabularies.
|
|
|
|
Transient order:
|
|
Execution of any vocabulary makes it the first vocabulary
|
|
searched, replacing the previously selected transient
|
|
vocabulary.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
67
|
|
|
|
|
|
|
|
|
|
|
|
C. EXPERIMENTAL PROPOSALS
|
|
|
|
|
|
Resident order:
|
|
After searching the transient order, up to three additional
|
|
vocabularies may be searched. The application program
|
|
controls this selection.
|
|
|
|
|
|
7 GLOSSARY
|
|
|
|
ONLY -- ONLY
|
|
Select just the ONLY vocabulary as both the transient
|
|
vocabulary and resident vocabulary in the search order.
|
|
|
|
FORTH -- ONLY
|
|
The name of the primary vocabulary. Execution makes FORTH
|
|
the transient vocabulary, the first in the search order, and
|
|
thus replaces the previous transient vocabulary.
|
|
|
|
ALSO -- ONLY
|
|
The transient vocabulary becomes the first vocabulary in the
|
|
resident portion of the search order. Up to the last two
|
|
resident vocabularies will also be reserved, in order,
|
|
forming the resident search order.
|
|
|
|
ORDER -- ONLY
|
|
Display the vocabulary names forming the search order in
|
|
their present search order sequence. Then show the
|
|
vocabulary into which new definitions will be placed.
|
|
|
|
WORDS -- ONLY
|
|
Display the word names in the transient vocabulary, starting
|
|
with the most recent definition.
|
|
|
|
FORGET -- ONLY
|
|
Used in the form:
|
|
FORGET <name>
|
|
Delete from the dictionary <name> and all words added to the
|
|
dictionary after <name> regardless of the vocabulary.
|
|
Failure to find <name> is an error condition. An error
|
|
condition also exists upon implicitly forgetting a
|
|
vocabulary (due to its definition after <name>).
|
|
|
|
DEFINITIONS -- ONLY
|
|
Select the transient vocabulary as the current vocabulary
|
|
into which subsequent definitions will be added.
|
|
|
|
SEAL -- ONLY
|
|
Delete all occurances of ONLY from the search order. The
|
|
effect is that only specified application vocabularies will
|
|
be searched.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
68
|
|
|
|
|
|
|
|
|
|
|
|
C. EXPERIMENTAL PROPOSALS
|
|
|
|
|
|
8 TYPICAL SOURCE CODE
|
|
|
|
0 ( ALSO ONLY 82jun12 WFR )
|
|
1 ( note the systems -FIND searches 1 to 5 vocabs in CONTEXT )
|
|
2 VOCABULARY ONLY ONLY DEFINITIONS
|
|
3 : ALSO ( slide transient into resident )
|
|
4 CONTEXT DUP 2+ 6 CMOVE> ;
|
|
5
|
|
6 HERE 2+ ] ( alter run time from usual vocabulary )
|
|
7 DOES> CONTEXT 8 ERASE DUP CONTEXT ! CONTEXT 8 + !
|
|
8 ALSO EXIT [
|
|
9 ' ONLY CFA ! ( Patch into ONLY; make NULL word )
|
|
10 CREATE X ' EXIT >BODY X ! 41088 ' X NFA ! IMMEDIATE
|
|
11 : FORTH FORTH ;
|
|
12 : DEFINITIONS DEFINITIONS ; : FORGET FORGET ;
|
|
13 : VOCABULARY VOCABULARY ; : ONLY ONLY ;
|
|
14 : WORDS WORDS ;
|
|
15
|
|
|
|
0 ( ORDER 82jun12 WFR )
|
|
1 : ORDER ( show the search order )
|
|
2 10 SPACES CONTEXT 10 OVER + SWAP
|
|
3 DO I @ ?DUP 0= ?LEAVE ID. 2 +LOOP
|
|
4 10 SPACES CURRENT @ ID. ;
|
|
5
|
|
6 ONLY FORTH ALSO DEFINITIONS
|
|
7
|
|
8
|
|
9
|
|
10
|
|
11
|
|
12
|
|
13
|
|
14
|
|
15
|
|
|
|
|
|
9 EXAMPLES OF USE
|
|
|
|
ONLY reduce search order to minimum
|
|
FORTH search FORTH then ONLY
|
|
ALSO EDITOR search EDITOR, FORTH then ONLY
|
|
DEFINITIONS new definitions will be added into the EDITOR
|
|
|
|
The same sequence would be compiled:
|
|
|
|
: SETUP ONLY FORTH ALSO EDITOR DEFINITIONS ;
|
|
|
|
|
|
10 REFERENCES
|
|
|
|
W. F. Ragsdale, The 'ONLY' Concept for Vocabularies, Proceedings
|
|
of the 1982 FORML Conference, pub. Forth Interest Group.
|
|
|
|
|
|
|
|
|
|
69
|
|
|
|
|
|
|
|
|
|
|
|
C. EXPERIMENTAL PROPOSALS
|
|
|
|
|
|
W. F. Ragsdale, fig-FORTH Installation Manual, Forth Interest
|
|
Group.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
70
|
|
|
|
|
|
|
|
|
|
|
|
C. EXPERIMENTAL PROPOSALS
|
|
|
|
|
|
|
|
|
|
|
|
|
|
DEFINITION FIELD ADDRESS CONVERSION OPERATORS
|
|
|
|
|
|
by
|
|
|
|
Kim R. Harris
|
|
|
|
|
|
A. INTRODUCTION
|
|
|
|
The standard provides a transportable way to obtain the
|
|
compilation address of a definition in the dictionary of a FORTH
|
|
system (cf., FIND and ' ). It also provides an operator to
|
|
convert a compilation address to its corresponding parameter
|
|
field address. However, the standard does not provide a
|
|
transportable way to convert either of these addresses to the
|
|
other fields of a definition. Since various FORTH
|
|
implementations have different dictionary structures, a standard
|
|
set of conversion operators would increase transportability and
|
|
readability.
|
|
|
|
A set of words is proposed which allows the conversion of any
|
|
definitions field address to any other.
|
|
|
|
|
|
B. GLOSSARY
|
|
|
|
In the following words, the compilation address is either the
|
|
source or the destination, so it is not indicated in the names.
|
|
|
|
>BODY addr1 -- addr2 "to-body"
|
|
addr2 is the parameter field address corresponding to the
|
|
compilation address addr1.
|
|
|
|
>NAME addr1 -- addr2 "to-name"
|
|
addr2 is the name field address corresponding to the
|
|
compilation address addr1.
|
|
|
|
>LINK addr1 -- addr2 "to-link"
|
|
addr2 is the link field address corresponding to the
|
|
compilation address addr1.
|
|
|
|
BODY> addr1 -- addr2 "from-body"
|
|
addr2 is the compilation address corresponding to the
|
|
parameter field address addr1.
|
|
|
|
NAME> addr1 -- addr2 "from-name"
|
|
addr2 is the compilation address corresponding to the name
|
|
field address addr1.
|
|
|
|
|
|
|
|
|
|
71
|
|
|
|
|
|
|
|
|
|
|
|
C. EXPERIMENTAL PROPOSALS
|
|
|
|
|
|
LINK> addr1 -- addr2 "from-link"
|
|
addr2 is the compilation address corresponding to the link
|
|
field address addr1.
|
|
|
|
The previous set of words is complete, but may be inefficient for
|
|
going between two fields when one is not the compilation address.
|
|
For greater efficiency, additional operators may be defined which
|
|
name both the source and destination fields.
|
|
|
|
N>LINK addr1 -- addr2 "name-to-link"
|
|
addr2 is the link field address corresponding to the name
|
|
field address addr1.
|
|
|
|
L>NAME addr1 -- addr2 "link-to-name"
|
|
addr2 is the name field address corresponding to the link
|
|
field address addr1.
|
|
|
|
|
|
C. DISCUSSION
|
|
|
|
The previous words provide a complete, consistent, and efficient
|
|
set of definition field address conversion operations. They can
|
|
be implemented in a FORTH system which uses any combination of
|
|
the following options for its dictionary structure:
|
|
|
|
Link fields first or second.
|
|
Fixed or variable length name fields.
|
|
Additional fields in the definitions structure.
|
|
|
|
Heads contiguous or separated from bodies.
|
|
|
|
Indirect, direct, subroutine, or token threaded code.
|
|
|
|
The words are compatible with this standard; their inclusion
|
|
would not require other changes to be made to the standard.
|
|
|
|
Disadvantages to including them in the standard include:
|
|
|
|
They add 6 to 8 more words to the standard.
|
|
|
|
A standard program may not use all of them since it is not
|
|
allowed to access the name or link fields. However, this
|
|
does not disqualify them from being in the standard.
|
|
|
|
If a definition's head is not in the dictionary, an error
|
|
condition would exist. In this case, what action should the
|
|
words take in an implemented system?
|
|
|
|
The author of this experimental proposal recommends that FORTH
|
|
system implementors try them and that they be included in the
|
|
System Word Set of the next FORTH standard.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
72
|
|
|
|
|
|
|
|
|
|
|
|
C. EXPERIMENTAL PROPOSALS
|
|
|
|
|
|
D. SOURCE CODE EXAMPLE
|
|
|
|
High level source code is shown below for a very simple
|
|
dictionary structure. This code assumes a FORTH system which
|
|
uses indirect threaded code, heads contiguous to bodies, and a
|
|
definition structure of the following format:
|
|
|
|
Name field, 4 bytes long, fixed length.
|
|
Link field, 2 bytes long.
|
|
Code field, 2 bytes long.
|
|
Parameter field, variable length.
|
|
|
|
: >BODY ( acf -- apf ) 2+ ;
|
|
: BODY> ( apf -- acf ) 2- ;
|
|
: >LINK ( acf -- alf ) 2- ;
|
|
: LINK> ( alf -- acf ) 2- ;
|
|
: >NAME ( acf -- anf ) 6 - ;
|
|
: NAME> ( anf -- alf ) 6 + ;
|
|
: N>LINK ( anf -- alf ) 4 + ;
|
|
: L>NAME ( alf -- anf ) 4 - ;
|
|
|
|
|
|
E. EXAMPLES OF USE
|
|
|
|
No examples are given because their use should be obvious.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
73
|
|
|