Source: uho/F83:
Copyright © 1983 Forth Standards Team
Permission is hereby granted to reproduce this document in whole or in part provided that such reproductions refer to the fact that the copied material is subject to copyright by the FORTH Standards Team. No changes or modifications may be made to the copied material unless it is clearly indicated that such changes were not incorporated in the original copyrighted work.
The existence of a FORTH Standard does not in any respect preclude anyone, whether the individual has approved this Standard or not, from implementing, marketing, purchasing or using products, processes, or procedures not conforming to the Standard. FORTH Standards are subject to periodic review and users are cautioned to obtain the latest editions.
ISBN 0-914699-03-2
FORTH STANDARDS TEAMAppendices
FORTH is an integrated programming approach and computer language. FORTH was invented by Mr. Charles Moore specifically to increase programmer productivity in the development of computer related applications without sacrificing machine efficiency. FORTH is a layered environment containing the elements of a computer language as well as those of an operating system and a machine monitor. This extensible, layered environment provides for highly interactive program development and testing.
In the interests of transportability of application software written in FORTH, standardization efforts began in the mid-1970s by the European FORTH User's Group (EFUG). This effort resulted in the FORTH-77 Standard. As the language continued to evolve, an interim FORTH-78 Standard was published by the FORTH Standards Team. Following FORTH Standards Team meetings in 1979 the FORTH- 79 Standard was published in 1980.
The FORTH Standards Team is comprised of individuals who have a great variety of experience and technical expertise with FORTH. The FORTH Standards Team consists of both users and implementers. Comments, proposals, and correspondence should be mailed to: FORTH Standards Team, P.O. Box 4545, Mountain View, CA 94040 USA.
FORTH's extensibility allows the language to be expanded and adapted to special needs and different hardware systems. A programmer or vendor may choose to strictly adhere with the standard, but the choice to deviate is acknowledged as beneficial and sometimes necessary. If the standard does not explicitly specify a requirement or restriction, a system or application may utilize any choice without sacrificing compliance to the standard provided that the system or application remains transportable and obeys the other requirements of the standard.
2The purpose of this standard is to allow transportability of FORTH-83 Standard Programs in source form among FORTH-83 Standard Systems. A standard program shall execute equivalently on all standard systems.
This standard shall apply to any FORTH-83 Standard Program executing on any FORTH-83 Standard System, provided sufficient computer resources (memory, mass storage) are available.
3When conflicting choices are made, the following order guides the Standards Team:
[COMPILE]
rather than 'C
,
and ALLOT
rather than DP+!
;These are the definitions of the terms used within this Standard.
An unsigned 16-bit number that locates an 8-bit byte in a standard FORTH address space over the range {0..65,535}. It may be a native machine address or a representation on a virtual machine, locating the addr-th byte within the virtual byte address space. Addresses are treated as unsigned numbers. See: "arithmetic, two's complement"
The numerical value compiled for a FORTH word definition which identifies that definition. The address interpreter uses this value to locate the machine code corresponding to each definition.
The natural address representation of the host computer.
The address of the first byte of memory associated with a word definition for the storage of compilation addresses (in a colon definition), numeric data, text characters, etc.
Arithmetic is performed using two's complement integers within a field of either 16 or 32 bits as indicated by the operation. Addition and subtraction of two's complement integers ignore any overflow condition. This allows numbers treated as unsigned to produce the same results as if the numbers had been treated as signed.
The 1024 bytes of data from mass storage which are referenced by block numbers in the range {0..the number of blocks available -1}. The actual amount of data transferred and the translation from block number to device and physical record is a function of the implementation. See: "block buffer" "mass storage"
A 1024-byte memory area where a block is made temporarily available for use. Block buffers are uniquely assigned to blocks. See: "9.7 Multiprogramming Impact"
An assembly of 8 bits. In reference to memory, it is the storage capacity for 8 bits. 5
A 7-bit number the significance of which is given by the ASCII standard. When contained in a larger field, the higher order bits are zero. See: "6. REFERENCES"
The action of converting text words from the input stream into an internal form suitable for later execution. When in the compile state, the compilation addresses of FORTH words are compiled into the dictionary for later execution by the address interpreter. Numbers are compiled to be placed on the data stack when later executed. Numbers are accepted from the input stream unsigned or negatively signed and converted using the value of BASE . See: "number" "number conversion" "interpreter, text"
A word that, when executed, creates a new dictionary entry in the compilation vocabulary. The new word name is taken from the input stream. If the input stream is exhausted before the new name is available, an error condition exists. Example of defining words are: : CONSTANT CREATE
See: "word definition"
A structure of word definitions in computer memory which is extensible and grows toward higher memory addresses. Entries are organized in vocabularies to aid location by name. See: "search order"
The process of sending one or more characters to the current output device. These characters are typically displayed or printed on a terminal. The selection of the current output device is system dependent.
Integer division in which the remainder carries the sign of the divisor or is zero, and the quotient is rounded to its arithmetic floor. Note that, except for error conditions, n1 n2 SWAP OVER /MOD ROT * + is identical to n1. See: "floor, arithmetic"
Examples:
dividend | divisor | remainder | quotient |
---|---|---|---|
10 | 7 | 3 | 1 |
-10 | 7 | 4 | -2 |
10 | -7 | -4 | -2 |
-10 | -7 | -3 | 1 |
A standard program will produce the same results, exclusive of timing dependencies, when given the same inputs on any Standard System which has sufficient resources to execute the program. Only standard source programs are transportable.
An exceptional condition which requires action by the system which may be other than the expected function. Refer to the section "10. Error Conditions".
A zero number represents the false state of a flag.
A number that may have one of two logical states, false or true. See: "false" "true"
If z is any real number, then the floor of z is the greatest
integer less than or equal to z.
The floor of +.6 is 0
The floor of -.4 is -1
Numbers are converted using the value of BASE and then displayed with no leading zeros. A trailing space is displayed. The number of characters displayed is the minimum number of characters, at least one, to uniquely represent the number. See: "number conversion"
A set of explanations in natural language to describe the corresponding computer execution of word definitions.
A word which executes when encountered during compilation or interpretation. Immediate words handle special cases during compilation. See, for example, IF LITERAL ." etc.
A sequence of characters available to the system, for processing by the text interpreter. The input stream conventionally may be taken from the current input device (via the text input buffer) and mass storage (via a block buffer). BLK , >IN , TIB and #TIB specify the input stream. Words using or altering BLK , >IN , TIB and #TIB are responsible for maintaining and restoring control of the input stream. 7
The input stream extends from the offset value of >IN to the size of the input stream. If BLK is zero the input stream is contained within the area addressed by TIB and is #TIB bytes long. If BLK is non-zero the input stream is contained within the block buffer specified by BLK and is 1024 bytes long. See: "11.8 Input Text"
The machine code instructions, routine or other facilities that execute compiled word definitions containing compilation addresses.
The word definitions(s) that repeatedly accepts a word name from the input stream, locates the corresponding compilation address and starts the address interpreter to execute it. Text from the input stream interpreted as a number leaves the corresponding value on the data stack. Numbers are accepted from the input stream unsigned or negatively signed and converted using the value of BASE . See: "number" "number conversion"
The grouping of word names of each Standard word set to show like characteristics. No implementation requirements are implied by this grouping.
Word definitions which add new procedures to the dictionary or which aid compilation by adding compilation addresses or data structures to the dictionary.
Word definitions which allow access to mass storage and computer peripheral devices.
Word definitions which support vocabularies, terminal output, and the interpretation of text from the text input buffer or a mass storage device by executing the corresponding word definitions.
Word definitions generally defined in machine code that control the execution of the fundamental operations of a virtual FORTH machine. This includes the address interpreter.
Redirection of the text interpreter's input stream to be from mass storage. This is the general method for compilation of new definitions into the dictionary. 8
Storage which might reside outside FORTH's address space. Mass storage data is made available in the form of 1024-byte blocks. A block is accessible within the FORTH address space in a block buffer. When a block has been indicated as UPDATEed (modified) the block will ultimately be transferred to mass storage.
When values exist within a larger field, the most- significant bits are zero. 16-bit numbers are represented in memory by addressing the first of two bytes at consecutive addresses. The byte order is unspecified by this Standard. Double numbers are represented on the stack with the most-significant 16 bits (with sign) most accessible. Double numbers are represented in memory by two consecutive 16-bit numbers. The address of the least significant 16 bits is two greater than the address of the most significant 16 bits. The byte order within each 16-bit field is unspecified. See: "arithmetic, two's complement" "number types" "9.8 Numbers" "11.7 Stack Parameters"
Numbers are maintained internally in binary and represented externally by using graphic characters within the ASCII character set. Conversion between the internal and external forms is performed using the current value of BASE to determine the digits of a number. A digit has a value ranging from zero to the value of BASE-1. The digit with the value zero is represented by the ASCII character "0" (position 3/0 with the decimal equivalent of 48). This representation of digits proceeds through the ASCII character set to the character "(" corresponding to the decimal value 9. For digits with a value exceeding 9, the ASCII graphic characters beginning with the character "A" (position 4/1 with the decimal equivalent 65) corresponding to the decimal value 10 are used. This sequence then continues up to and including the digit with the decimal value 71 which is represented by the ASCII character "~" (position 7/14 with a decimal equivalent 126). A negative number may be represented by preceding the digits with a single leading minus sign, the character "-".
All number types consist of some number of bits. These bits are either arbitrary or are weighted. 9
Signed and unsigned numbers use weighted bits. Weighted bits within a number have a value of a power of two beginning with the rightmost (least-significant) bit having the value of two to the zero power. This weighting continues to the leftmost bit increasing the power by one for each bit. For an unsigned number this weighting pattern includes the leftmost bit; thus, for an unsigned 16-bit number the weight of the leftmost bit is 32,768. For a signed number this weighting pattern includes the leftmost bit but the weight of the leftmost bit is negated; thus, for a signed 16-bit number the weight of the leftmost bit is -32,768. This weighting pattern for signed numbers is called two's complement notation.
Unspecified weighted numbers are either unsigned numbers or signed numbers; program context determines whether the number is signed or unsigned. See: "11.7 Stack Parameters"
The use of numeric output definitions which convert numerical values into text strings. These definitions are used in a sequence which resembles a symbolic 'picture' of the desired text format. Conversion proceeds from least- significant digit to most-significant digit, and converted characters are stored from higher memory addresses to lower.
A complete specification of execution to achieve a specific function (application task) expressed in FORTH source code form.
The process of obtaining one character from the current input device. The selection of the current input device is system dependent.
The process of self-reference, either directly or indirectly.
The means of indicating the end of text by striking a key on an input device. The key used is system dependent. This key is typically called "RETURN", "CARRIAGE RETURN", or "ENTER".
Textual data arranged for editing. By convention, a screen consists of 16 lines (numbered 0 through 15) of 64 characters each. Screens usually contain program source text, but may be used to view mass storage data. The first byte of a screen occupies the first byte of a mass storage block, which is the beginning point for text interpretation during a load. 10
A specification of the order in which selected vocabularies in the dictionary are searched. Execution of a vocabulary makes it the first vocabulary in the search order. The dictionary is searched whenever a word is to be located by its name. This order applies to all dictionary searches unless otherwise noted. The search order begins with the last vocabulary executed and ends with FORTH , unless altered in a system dependent manner.
Text consisting of word names suitable for compilation or execution by the text interpreter. Such text is usually arranged in screens and maintained on a mass storage device.
A last in, first out list consisting of 16-bit binary values. This stack is primarily used to hold intermediate values during execution of word definitions. Stack values may represent numbers, characters, addresses, boolean values, etc.
When the name 'stack' is used alone, it implies the data stack.
A last in, first out list which contains the addresses of word definitions whose execution has not been completed by the address interpreter. As a word definition passes control to another definition, the return point is placed on the return stack.
The return stack may cautiously be used for other values.
A sequence of consecutive 8-bit bytes located in memory by their low memory address. The byte at this address contains a count {0..255} of the number of bytes following which are part of the string. The count does not include the count byte itself. Counted strings usually contain ASCII characters.
A sequence of consecutive 8-bit bytes located in memory by their low memory address and length in bytes. Strings usually, but not exclusively, contain ASCII characters. When the term 'string' is used alone or in conjunction with other words it refers to text strings. 11
A group of FORTH words which when executed alter the
execution sequence. The group starts and terminates with
compiler words. Examples of control structures: DO ...
LOOP DO ... +LOOP BEGIN ... WHILE ... REPEAT BEGIN ...
UNTIL IF ... THEN IF ... ELSE ... THEN
See: "9.9 Control
Structures"
This term indicates that equivalent execution results when a program is executed on other than the system on which it was created. See: "equivalent execution"
A non-zero value represents the true state of a flag. Any non-zero value will be accepted by a standard word as 'true'; all standard words return a 16-bit value with all bits set to one when returning a 'true' flag.
An area in memory which contains the storage for user variable.
A variable whose data storage area is usually located in the user area. Some system variables are maintained in the user area so that the words may be re-entrant to different users.
An ordered list of word definitions. Vocabularies are an advantage in separating different word definitions that may have the same name. More than one definition with the same name can exist in one vocabulary. The latter is called a redefinition. The most recently created redefinition will be found when the vocabulary is searched.
The vocabulary into which new word definitions are appended.
A sequence of characters terminated by one blank or the end of the input stream. Leading blanks are ignored. Words are usually obtained via the input stream.
A named FORTH execution procedure compiled into the dictionary. Its execution may be defined in terms of machine code, as a sequence of compilation address, or other compiled words. 12
The name of a word definition. Word names are limited to 31 characters and may not contain an ASCII space. If two definitions have different word names in the same vocabulary they must be uniquely findable when this vocabulary is searched. See: "vocabulary" "9.5.3 EXPECT"
A named group of FORTH word definitions in the Standard.
Additional words which facilitate programming in the native machine language of the computer which are by nature system dependent.
Additional words which facilitate manipulation of 32-bit numbers.
The minimum words needed to compile and execute Standard Programs.
Additional words which facilitate the access to internal system characteristics.
A named FORTH procedure definition, in the Required word set or any extension word sets, formally reviewed and accepted by the Standards Team.
The following document is considered to be a portion of this Standard:
American National Standard Code for Information Interchange, X3.4-1977 (ASCII), American National Standards Institute, 1430 Broadway, New York, NY 10018, USA.
The following documents are noted as pertinent to the FORTH-83 Standard, but are not part of this Standard.
FORTH-77, FORTH Users Group, FST-780314
FORTH-78, FORTH International Standards Team
FORTH-79, FORTH Standards Team
FORTH-83 STANDARD, Appendices, FORTH Standards Team
Webster's Collegiate Dictionary shall be used to resolve conflicts in spelling and English word usage. 14
7.1.1 Each Standard System shall be accompanied by a statement of:
7.1.2 Each standard program shall be accompanied by a statement of the minimum requirements for:
The following host computer configuration is specified as a minimum environment for testing against this Standard. Applications may require different capacities.
The FORTH Standards Team hereby specifies the requirements for labeling of systems and applications so that the conditions for program portability may be established.
A Standard System may use the specified labeling if it complies with the terms of this Standard and meets the particular Word Set definitions.
A Standard Program (application) may use the specified labeling if it utilizes the specified Standard System according to this Standard and executes equivalently on any such system.
In a system or application, a standard word may not be redefined to perform a different function within the vocabulary FORTH.
A system may be labeled:
FORTH-83 Standard
if it includes all of the Required Word Set in either source or object form and complies with the text of this Standard. After executing "FORTH-83" the dictionary must contain all of the Required Word Set in the vocabulary FORTH, as specified in this Standard.
A system may be labeled:
FORTH-83 Standard Sub-set
if it includes a portion of the Required Word Set and complies with the remaining text of this Standard. However, no Required Word may be present with a non-standard definition.
A system may be labeled:
FORTH-83 Standard with <name> Standard Extension(s)
if it comprises a FORTH-83 Standard System and one or more Standard Extension Word Set(s). For example, a designation would be in the form: 17
FORTH-83 Standard with Double-Number Standard Extension
A FORTH source program which executes equivalently on any Standard System may be labeled:
FORTH-83 Standard Program
See: "equivalent execution" "7. REQUIREMENTS"
A program which is standard in all ways except for specific environmentally dependent words may be labeled:
FORTH-83 Standard Program with Environmental Dependencies
if the following additional requirements are met:
1) Environmental dependencies (including hardware dependencies) shall be factored into an isolated set of application word definitions.
2) Each environmentally dependent word definition must be fully documented, including all dependencies in a manner at least as detailed as the standard words.
A Standard Program may reference only the definitions of the Required Word Set and Standard Extensions and definitions which are subsequently defined in terms of these words. Furthermore, A Standard Program must use the standard words as required by any conventions of this Standard. Equivalent execution must result from Standard Programs.
The implementation of a Standard System may use words and techniques outside the scope of the Standard, provided that no program running on that system is required to use words outside the Standard for normal operation.
If a Standard System or Standard Program redefines Standard definitions within the FORTH vocabulary, these definitions must comply with the Standard.
The FORTH system may share the dictionary space with the user's application. The native addressing protocol of the host computer is beyond the scope of this Standard.
Therefore, in a Standard Program, the user may only operate on data which was stored by the application. No exceptions!
A Standard Program may address:
A Standard Program may NOT address:
A Standard Program may cautiously use the return stack with the following restrictions:
The return stack may not be accessed inside a do-loop for values placed on the return stack before the loop was entered. Further, neither I nor J may be used to obtain the index of a loop if values are placed and remain on the return stack within the loop. When the do-loop is executed all values placed on the return stack within that loop must be removed before LOOP , +LOOP , or LEAVE is executed. Similarly, all values placed on the return stack within a colon definition must be removed before the colon definition is terminated at ; or before EXIT is executed.
The system uses the return stack and the dictionary in a system dependent manner during the compilation of colon definitions. Some words use the data stack in a system dependent manner during compilation. See: "sys (11.7)"
A Standard System must receive all valid ASCII characters. Each KEY receives one ASCII character, with more-significant bits environmentally dependent and might be zero. KEY must receive as many bits as are obtainable. A Standard Program without environmental dependencies may only use the least significant 7- bit ASCII character received by KEY . For example: KEY 127 AND
Control characters may be processed to allow system dependent editing of the characters prior to receipt. Therefore, a Standard Program may not anticipated that control characters can be received. 20
Because of the potential non-transportable action by terminal devices of control characters, the use of ASCII control characters is an environmental dependency. Each EMIT deals with only one ASCII character. The ASCII character occupies the least-significant 7 bits; the more-significant bits may be environmentally dependent. Using the more-significant bits when other than zero is an environmentally dependent usage. EMIT must display as many bits as can be sent.
Because of the potential non-transportable action by terminal devices of control characters, the use of ASCII control characters is an environmental dependency.
Further usage requirements are expected to be added for transporting programs between Standard Systems.
In a multiprogrammed system, Device Layer words and those words which implicitly reference the Device Layer words may relinquish control of the processor to other tasks. Although there is insufficient experience to specify a standard for multiprogramming, historical usage dictates that a programmer be aware of the potential impact with regard to resources shared between tasks. The only shared resources specified within the Standard are block buffers. Therefore the address of a block buffer returned by BLOCK or BUFFER becomes invalid during and after the execution of any word marked by the attribute M in the glossary or any words executing them. A block buffer is valid only if its address is valid. See: "11.4 Attributes"
Interpreted or compiled numbers are in the range {-32,768..65,535}. See: "number conversion"
Control structures are compiled inside colon definitions. Control structures can be nested but cannot overlap. For additional limitations see DO . 21
When an error condition occurs, a Standard System may take one or more of the following actions:
See: "7.1 Documentation Requirements"
The following error conditions apply in many situations. These error conditions are listed below, but may occur at various times and with various words.
The glossary definitions are listed in ASCII alphabetical order.
Word names are capitalized throughout this Standard.
The stack parameters input to and output from a definition are described using the notation:
before -- after
In this notation, the top of the stack is to the right. Words may also be shown in context when appropriate.
Unless otherwise noted, all stack notation describes exectution time. If it applies at compile time, the line is followed by: (compiling) .
Capitalized symbols indicate attributes of the defined words:
When a substantive alteration to a word's definition is made or when a new word is added, the serial number will be the last two digits of the year of the Standard in which such change was made (i.e., "83"). When such change is made within a Working Draft, the number will be suffixed with the character identifying the draft (i.e., "83A").
The natural language pronunciation of word names is given in double quotes (") where it differs from English pronunciation.
Unless otherwise stated, all references to numbers apply to 16- bit signed integers. The implied range of values is shown as {from..to}. The contents of an address is shown by double braces, particularly for the contents of variables, i.e., BASE {{2..72}}.
The following are the stack parameter abbreviations and types of numbers used throughout the glossary. These abbreviations may be suffixed with a digit to differentiate multiple parameters of the same type. 25
Stack Abbrv. | Number Type | Range in Decimal | Minimum Field |
---|---|---|---|
flag | boolean | 0=false, else=true | 16 |
true | boolean | -1 (as a result) | 16 |
false | boolean | 0 | 16 |
b | bit | {0..1} | 1 |
char | character | {0..127} | 7 |
8b | 8 arbitrary bits (byte) | not applicable | 8 |
16b | 16 arbitrary bits | not applicable | 16 |
n | number (weighted bits) | {-32,768..16 | |
+n | positive number | {0..32,767} | 16 |
u | unsigned number | {0..65,535} | 16 |
w | unspecified weighted number (n or u) | {-32,768..16 | |
addr | address (same as u) | {0..65,535} | 16 |
32b | 32 arbitrary bits | not applicable | 32 |
d | double number | {-2,147,483,648..32 | |
+d | positive double number | {0..32 | |
ud | unsigned double number | {0..32 | |
wd | unspecified weighted double number (d or ud) | {-2,147,483,648..32 | |
sys | 0, 1, or more system dependent stack entries | not applicable | na |
Any other symbol refers to an arbitrary signed 16-bit integer in the range {-32,768..32,767}, unless otherwise noted.
Because of the use of two's complement arithmetic, the signed 16- bit number (n) -1 has the same bit representation as the unsigned number (u) 65,535. Both of these numbers are within the set of unspecified weighted numbers (w). See: "arithmetic, two's complement" "number" "number types" "stack, data"
Glossary definitions may refer to other glossary definitions or to definitions of terms. Such references are made using the expression "See:". These references provide additional information which apply as if the information is a portion of the glossary entry using "See:". 27
The words of the Required Word Set are grouped to show like characteristics. No implementation requirements should be inferred from this grouping.
! * */ */MOD + +! - / /MOD 0< 0= 0> 1+ 1- 2+
2- 2/ < = > >R ?DUP @ ABS AND C! C@ CMOVE
CMOVE> COUNT D+ D< DEPTH DNEGATE DROP DUP EXECUTE
EXIT FILL I J MAX MIN MOD NEGATE NOT OR OVER PICK
R> R@ ROLL ROT SWAP U< UM* UM/MOD XOR
BLOCK BUFFER CR EMIT EXPECT FLUSH KEY SAVE-BUFFERS
SPACE SPACES TYPE UPDATE
# #> #S #TIB ' ( -TRAILING . .( <# >BODY >IN
ABORT BASE BLK CONVERT DECIMAL DEFINITIONS FIND
FORGET FORTH FORTH-83 HERE HOLD LOAD PAD QUIT SIGN
SPAN TIB U. WORD
+LOOP , ." : ; ABORT" ALLOT BEGIN COMPILE CONSTANT
CREATE DO DOES> ELSE IF IMMEDIATE LEAVE LITERAL LOOP
REPEAT STATE THEN UNTIL VARIABLE VOCABULARY WHILE [
['] [COMPILE] ]
!
16b addr --
79 "store"#
+d1 -- +d2
79 "sharp"#>
32b -- addr +n
79 "sharp-greater"#S
+d -- 0 0
79 "sharp-s"#TIB
-- addr
U,83 "number-t-i-b"'
-- addr
M,83 "tick"(
--
I,M,83 "paren"--
(compiling)*
w1 w2 -- w3
79 "times"*/
n1 n2 n3 -- n4
83 "times-divide"*/MOD
n1 n2 n3 -- n4 n5
83 "times-divide-mod"+
w1 w2 -- w3
79 "plus"+!
w1 addr --
79 "plus-store"+LOOP
n --
C,I,83 "plus-loop"sys --
(compiling),
16b --
79 "comma"-
w1 w2 -- w3
79 "minus"-TRAILING
addr +n1 -- addr +n2
79 "dash-trailing".
n --
M,79 "dot"."
--
C,I,83 "dot-quote"--
(compiling).(
--
I,M,83 "dot-paren"--
(compiling)/
n1 n2 -- n3
83 "divide"/MOD
n1 n2 -- n3 n4
83 "divide-mod"0<
n -- flag
83 "zero-less"0=
w -- flag
83 "zero-equals"0>
n -- flag
83 "zero-greater"1+
w1 -- w2
79 "one-plus"1-
w1 -- w2
79 "one-minus"2+
w1 -- w2
79 "two-plus"2-
w1 -- w2
79 "two-minus"2/
n1 -- n2
83 "two-divide":
-- sys
M,79 "colon"A defining word executed in the form:
: <name> ... ;
Create a word definition for <name> in the compilation vocabulary and set compilation state. The search order is changed so that the first vocabulary in the search order is replaced by the compilation vocabulary. The compilation vocabulary is unchanged. The text from the input stream is subsequently compiled. <name> is called a "colon definition". The newly created word definition for <name> cannot be found in the dictionary until the corresponding ; or ;CODE is successfully processed.
An error condition exists if a word is not found and cannot be converted to a number or if, during compilation from mass storage, the input stream is exhausted before encountering ; or ;CODE . sys is balanced with its corresponding ; . See: "compilation" "9.4 Compilation"
;
--
C,I,79 "semi-colon"sys --
(compiling)<
n1 n2 -- flag
83 "less-than"<#
--
79 "less-sharp"=
w1 w2 -- flag
83 "equals">
n1 n2 -- flag
83 "greater-than">BODY
addr1 -- addr2
83 "to-body">IN
-- addr
U,79 "to-in">R
16b --
C,79 "to-r"?DUP
16b -- 16b 16b or 0 -- 0
79 "question-dupe"@
addr -- 16b
79 "fetch"ABORT
79 ABORT"
flag --
C,I,83 "abort-quote"--
(compiling)ABS
n -- u
79 "absolute"ALLOT
w --
79 AND
16b1 16b2 -- 16b3
79 BASE
-- addr
U,83 BEGIN
--
C,I,79 -- sys
(compiling)BLK
-- addr
U,79 "b-l-k"BLOCK
u -- addr
M,83 BUFFER
u -- addr
M,83 C!
16b addr --
79 "c-store"C@
addr -- 8b
79 "c-fetch"CMOVE
addr1 addr2 u --
83 "c-move"CMOVE>
addr1 addr2 u --
83 "c-move-up"COMPILE
--
C,83 CONSTANT
16b --
M,83 CONVERT
+d1 addr1 -- +d2 addr2
79 COUNT
addr1 -- addr2 +n
79 CR
--
M,79 "c-r"CREATE
--
M,79 D+
wd1 wd2 -- wd3
79 "d-plus"D<
d1 d2 -- flag
83 "d-less-than"DECIMAL
--
79 DEFINITIONS
--
79 DEPTH
-- +n
79 DNEGATE
d1 -- d2
79 "d-negate"DO
w1 w2 --
C,I,83 -- sys
(compiling)DOES>
-- addr
C,I,83 "does"--
(compiling)Defines the execution-time action of a word created by a
high-level defining word. Used in the form:
: <namex> ... <create> ... DOES> ... ;
and then
<namex> <name>
where <create> is CREATE or any user defined word which
executes CREATE .
Marks the termination of the defining part of the defining word <namex> and then begins the definition of the execution-time action for words that will later be defined by <namex>. When <name> is later executed, the address of <name>'s parameter field is placed on the stack and then the sequence of words between DOES> and ; are executed.<7dd>
DROP
16b --
79 DUP
16b -- 16b 16b
79 "dupe"ELSE
--
C,I,79 sys1 -- sys2
(compiling)EMIT
16b --
M,83 EXECUTE
addr --
79 EXIT
--
C,79 EXPECT
addr +n --
M,83 FILL
addr u 8b --
83 FIND
addr1 -- addr2 n
83 FLUSH
--
M,83 FORGET
--
M,83 FORTH
--
83 FORTH-83
--
83 HERE
-- addr
79 HOLD
char --
79 I
-- w
C,79 IF
flag --
C,I,79 -- sys
(compiling)Used in the form:
flag IF ... ELSE ... THEN
or
flag IF ... THEN
If flag is true, the words following IF are executed and the
words following ELSE until just after THEN are skipped. The
ELSE part is optional.
If flag is false, the words from IF through ELSE , or from IF through THEN (when no ELSE is used), are skipped. sys is balanced with its corresponding ELSE or THEN . See: "9.9 Control Structures"
IMMEDIATE
--
79 J
-- w
C,79 KEY
-- 16b
M,83 LEAVE
--
C,I,83 --
(compiling)LITERAL
-- 16b
C,I,79 16b --
(compiling)LOAD
u --
M,79 LOOP
--
C,I,83 sys --
(compiling)MAX
n1 n2 -- n3
79 "max"MIN
n1 n2 -- n3
79 "min"MOD
n1 n2 -- n3
83 NEGATE
n1 -- n2
79 NOT
16b1 -- 16b2
83 OR
16b1 16b2 -- 16b3
79 OVER
16b1 16b2 -- 16b1 16b2 16b3
79 PAD
-- addr
83 PICK
+n -- 16b
83 QUIT
--
79 R>
-- 16b
C,79 "r-from"R@
-- 16b
C,79 "r-fetch"REPEAT
--
C,I,79 sys --
(compiling)ROLL
+n --
83 ROT
16b1 16b2 16b3 -- 16b2 16b3 16b1
79 "rote"SAVE-BUFFERS
--
M,79 "save-buffers"SIGN
n --
83 SPACE
--
M,79 SPACES
+n --
M,79 SPAN
-- addr
U,83 STATE
-- addr
U,79 SWAP
16b1 16b2 -- 16b2 16b1
79 THEN
--
C,I,79 sys --
(compiling)TIB
-- addr
83 "t-i-b"TYPE
addr +n --
M,79 U.
u --
M,79 "u-dot"U<
u1 u2 -- flag
83 "u-less-than"UM*
u1 u2 -- ud
83 "u-m-times"UM/MOD
ud u1 -- u2 u3
83 "u-m-divide-mod"UNTIL
flag --
C,I,79 sys --
(compiling)UPDATE
--
79 VARIABLE
--
M,79 VOCABULARY
--
M,83 WHILE
flag --
C,I,79 sys1 -- sys2
(compiling)WORD
char -- addr
M,83 Generates a counted string by non-destructively accepting characters from the input stream until the delimiting character char is encountered or the input stream is exhausted. Leading delimiters are ignored. The entire character string is stored in memory beginning at addr as a sequence of bytes. The string is followed by a blank which is not included in the count. The first byte of the string is the number of characters {0..255}. If the string is longer than 255 characters, the count is unspecified. If the input stream is already exhausted as WORD is called, then a zero length character string will result.
If the delimiter is not found the value of >IN is the size of the input stream. If the delimiter is found >IN is adjusted to indicate the offset to the character following the delimiter. #TIB is unmodified.
The counted string returned by WORD may reside in the "free" dictionary area at HERE or above. Note that the text interpreter may also use this area. See: "input stream"
XOR
16b1 16b2 -- 16b3
79 "x-or"[
--
I,79 "left-bracket"--
(compiling)[']
-- addr
C,I,M,83 "bracket-tick"--
(compiling)[COMPILE]
--
C,I,M,79 "bracket-compile"--
(compiling)]
--
79 "right-bracket"2! 2@ 2DROP 2DUP 2OVER 2ROT 2SWAP D+ D- D0= D2/
D< D= DABS DMAX DMIN DNEGATE DU<
none
D. D.R
2CONSTANT 2VARIABLE
46
2!
32b addr --
79 "two-store"2@
addr -- 32b
79 "two-fetch"2CONSTANT
32b --
M,83 "two-constant"2DROP
32b --
79 "two-drop"2DUP
32b -- 32b 32b
79 "two-dupe"2OVER
32b1 32b2 -- 32b1 32b2 32b3
79 "two-over"2ROT
32b1 32b2 32b3 -- 32b2 32b3 32b1
79 "two-rote"2SWAP
32b1 32b2 -- 32b2 32b1
79 "two-swap"2VARIABLE
--
M,79 "two-variable"D+
wd1 wd2 -- wd3
79 "d-plus"D-
wd1 wd2 -- wd3
79 "d-minus"D.
d --
M,79 "d-dot"D.R
d +n --
M,83 "d-dot-r"D0=
wd -- flag
83 "d-zero-equals"D2/
d1 -- d2
83 "d-two-divide"D<
d1 d2 -- flag
83 "d-less-than"D=
wd1 wd2 -- flag
83 "d-equal"DABS
d -- ud
79 "d-absolute"DMAX
d1 d2 -- d3
79 "d-max"DMIN
d1 d2 -- d3
79 "d-min"DNEGATE
d1 -- d2
79 "d-negate"DU<
ud1 ud2 -- flag
83 "d-u-less"none
none
ASSEMBLER
;CODE CODE END-CODE
Because of the system dependent nature of machine language programming, a Standard Program cannot use CODE or ;CODE .
49;CODE
--
C,I,79 "semi-colon-code"sys1 -- sys2
(compiling)ASSEMBLER
--
83 CODE
-- sys
M,83 END-CODE
sys --
79 "end-code"BRANCH ?BRANCH
none
CONTEXT CURRENT
<MARK <RESOLVE >MARK >RESOLVE
After BRANCH or ?BRANCH is compiled, >MARK or <RESOLVE is executed. The addr left by >MARK is passed to >RESOLVE . The addr left by <MARK is passed to <RESOLVE . For example:
: IF COMPILE ?BRANCH >MARK ; IMMEDIATE : THEN >RESOLVE ; IMMEDIATE
<MARK
-- addr
C,83 "backward-mark"<RESOLVE
addr --
C,83 "backward-resolve">MARK
-- addr
C,83 "forward-mark">RESOLVE
addr --
C,83 "forward-resolve"?BRANCH
flag --
C,83 "question-branch"BRANCH
--
C,83 CONTEXT
-- addr
U,79 CURRENT
-- addr
U,79 The Controlled Reference Words are word definitions which, although not required, cannot be present with a non-standard definition in the vocabulary FORTH of a Standard System. These words have present usage and/or are candidates for future standardization.
-->
--
I,M,79 "next-block"--
(compilation).R
n +n --
M,83 "dot-r"2*
w1 -- w2
83 "two-times"BL
-- 32
79 "b-l"BLANK
addr u --
83 C,
16b --
83 "c-comma"DUMP
addr u --
M,79 EDITOR
--
83 EMPTY-BUFFERS
--
M,79 "empty-buffers"END
flag --
C,I,79 sys --
(compiling)ERASE
addr u --
79 HEX
--
79 INTERPRET
--
M,83 K
-- w
C,83 LIST
u --
M,79 OCTAL
--
83 OFFSET
-- addr
U,83 QUERY
--
M,83 RECURSE
--
C,I,83 --
(compiling)SCR
-- addr
U,79 "s-c-r"SP@
-- addr
79 "s-p-fetch"THRU
u1 u2 --
M,83 U.R
u +n --
M,83 "u-dot-r"The following is a list in alphabetical order of the people who are FORTH Standards Team Members. These names are provided to indicate the texture and make-up of the team itself. Where appropriate, the official capacity of individuals is also indicated.
Paul Bartholdi, Sauverny, Switzerland
Robert Berkey, Palo Alto, California USA Treasurer
David Boulton, Redwood City, California USA
John Bumgarner, Morgan Hill, California USA
Don Colburn, Rockville, Maryland USA
James T. Currie, Jr., Blacksburg, Virginia USA
Thomas B. Dowling, Lowell, Massachusetts USA
William S. Emery, Malibu, California USA
Lawrence P. Forsley, Rochester, New York USA
Kim R. Harris, Palo Alto, California USA Referee
John S. James, Los Gatos, California USA
Guy M. Kelly, La Jolla, California USA Chair
Thea Martin, Rochester, New York USA
Michael McNeil, Scotts Valley, California USA
Robert E. Patten, Modesto, California USA
Michael Perry, Berkeley, California USA
David C. Petty, Cambridge, Massachusetts USA
William F. Ragsdale, Hayward, California USA
Elizabeth D. Rather, Hermosa Beach, California USA
Dean Sanderson, Hermosa Beach, California USA Referee
Klaus Schleisiek, Hamburg, W-Germany
George W. Shaw II, Hayward, California USA Referee
Robert L. Smith, Palo Alto, California USA Secretary
Michael K. Starling, Elkview, West Virginia USA
John K. Stevenson, Portland, Oregon USA
Glenn S. Tenney, San Mateo, California USA Referee
56
The following is a list in alphabetical order of individuals and organizations who have contributed funds and other assistance to aid the word of the FST and deserve recognition for their involvement. FST sponsors have no duties or responsibilities in the FST, but they receive copies of proposals and comments considered at a formal meeting, and drafts and adopted standards prepared as a result of that meeting.
Creative Solutions Inc., 4801 Randolph Rd., Rockville, MD 20852 USA
Fantasia Systems Inc., 1059 Alameda de las Pulgas, Belmont, CA 94002 USA
FORTH, Inc., 2309 Pacific Coast Highway, Hermosa Beach, CA 90254 USA
FORTH Interest Group Inc., P.O. Box 1105, San Carlos, CA 94070 USA
Forthright Enterprises, P.O. Box 50911, Palo Alto, CA 94020 USA
Glen Haydon Enterprises, Box 439 Rt. 2, La Honda, CA 94020 USA
John K. Gotwals, W. Lafayette, IN USA
John D. Hall, Oakland, CA USA
Hartronix, Inc., 1201 N. Stadem, Tempe, AZ 85281 USA
Hewlett-Packard Corvallis Div., 1000 NE Circle Blvd., Corvallis, OR 97330 USA
Information Unlimited Software, Inc., 2401 Marinship, Sausalito, CA 94965 USA
Henry H. Laxen, 1259 Cornell Avenue, Berkeley, CA 94705 USA
Laxen & Harris, Inc.
George B. Lyons, 280 Henderson Street, Jersey Cit, NJ 07302 USA
C. Kevin McCabe, Chicago, IL USA
MicroMotion, 12077 Wilshire Blvd #506, Los Angeles, CA 90025 USA
Bruce R. Montague, Monterey, CA USA
Mountain View Press, P.O. Box 4659, Mountain View, CA 94040 USA 57
Michael A. Perry, Berkeley, CA USA
Robert Berkey Services, 2334 Dumbarton Ave., Palo Alto, CA 94303 USA
Royal Greenwich Observatory, Herstmonsioux Castle, Eastbourne, England
Shaw Laboratories, Ltd., 24301 Southland Drive #216, Hayward, CA 94545 USA
Sygnetron Protection Systems, Inc., 2103 Greenspring, Timonium, MD 21093 USA
Telelogic Inc., 196 Broadway, Cambridge, MA 02139 USA
UNISOFT, P.O. Box 2644, New Carrollton, MD 20784 USA 58
The Uncontrolled Reference Word Set contains glossary definitions which are included for public reference of words that have past or present usage and/or are candidates for future standardization. No recommendation is made that these words be included in a system.
No restrictions are placed on the definition or usage of uncontrolled words. However, use of these names for procedures differing from the given definitions is discouraged.
!BITS
16b1 addr 16b2 --
"store-bits"**
n1 n2 -- n3
"power"+BLOCK
w -- u
"plus-block"-'
-- addr false or -- true
"dash-tick"-MATCH
addr1 +n1 addr2 +n2 -- addr3 flag
"dash-match"-TEXT
addr1 +n1 addr2 -- n2
"dash-text"/LOOP
+n --
C,I "up-loop"sys --
(compiling)1+!
addr --
"one-plus-store"1-!
addr --
"one-minus-store";:
-- addr
C,I "semi-colon-colon";S
--
Interpret only "semi-s"<>
w1 w2 -- flag
"not-equal"<BUILDS
--
C,M "builds"<CMOVE
addr1 addr2 u --
"reverse-c-move"><
16b1 -- 16b2
"byte-swap">MOVE<
addr1 addr2 u --
"byte-swap-move"@BITS
addr 16b1 -- 16b2
"fetch-bits"AGAIN
--
C,I sys --
(compiling)ASCII
-- char
I,M "as-key"--
(compiling)ASHIFT
16b1 n -- 16b2
"a-shift"B/BUF
-- 1024
"bytes-per-buffer"BELL
--
M CHAIN
--
M CONTINUED
u --
M CUR
-- addr
DBLOCK
ud -- addr
M "d-block"DPL
-- addr
U "d-p-l"FLD
-- addr
U "f-l-d"H.
u --
M "h-dot"I'
-- w
C "i-prime"IFEND
Interpret only "if-end"IFTRUE
flag --
Interpret only INDEX
u1 u2 --
M LAST
-- addr
U LINE
+n -- addr
M LINELOAD
+n u --
M "line-load"LOADS
u --
M MAP0
-- addr
"map-zero"MASK
n -- 16b
MOVE
addr1 addr2 u --
MS
+n --
M "m-s"NAND
16b1 16b2 -- 16b3
NOR
16b1 16b2 -- 16b3
NUMBER
addr -- d
O.
u --
M "o-dot"OTHERWISE
--
I PAGE
--
M READ-MAP
--
M "read-map"REMEMBER
--
M REWIND
--
M ROTATE
16b1 n -- 16b2
S0
-- addr
U "s-zero"SET
16b addr --
M SHIFT
16b1 n -- 16b2
TEXT
char --
M USER
+n --
M WORDS
--
M \LOOP
+n --
C,I "down-loop"sys --
(compiling)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. 66
WILLIAM F. RAGSDALE
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.
The following functions are required:
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.
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.
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 .
ONLY
--
ONLY FORTH
--
ONLY ALSO
--
ONLY ORDER
--
ONLY WORDS
--
ONLY FORGET
--
ONLY DEFINITIONS
--
ONLY SEAL
--
ONLY 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
W. F. Ragsdale, The 'ONLY' Concept for Vocabularies, Proceedings of the 1982 FORML Conference, pub. Forth Interest Group. 70
W. F. Ragsdale, fig-FORTH Installation Manual, Forth Interest Group.
71by
Kim R. Harris
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.
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">NAME
addr1 -- addr2
"to-name">LINK
addr1 -- addr2
"to-link"BODY>
addr1 -- addr2
"from-body"NAME>
addr1 -- addr2
"from-name"LINK>
addr1 -- addr2
"from-link"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"L>NAME
addr1 -- addr2
"link-to-name"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.
73High 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 - ;
No examples are given because their use should be obvious. 74
1.1.1 This Charter establishes and guides a voluntary membership professional organization, the FORTH Standards Team (hereafter referred to as the "FST") and provides a method for its operation.
1.2.1 The goal of the FST is the creation, maintenance, and proliferation of a standard (hereafter referred to as the "Standard") for the FORTH computer programming system and for application programs executed by a Standard system. The Standard shall specify requirements and constraints which such computer software must satisfy.
1.2.2 The team shall also develop a method of identification and labeling of FORTH implementations and programs which conform to the Standard.
1.3.1 The FST is a voluntary membership organization with no formal status as a legal entity. It operates by consensus of the professional and commercial FORTH community and conducts business by the professional discourse and agreement of its members. It is intended that this Charter be a guide to the operation of the FST subject to reasonable minor digression, rather than being a rigid document under which vested rights are granted. 75
2.1.1 The FST shall hold periodic formal meetings for discussion and decisions concerning a current or future Standard.
2.1.2 There is not specified frequency for formal meetings. Each meeting shall be at such time and place as was decided at the prior meeting. If a meeting cannot be held as decided, the Chairperson may designate another time and place.
2.1.3 The Chairperson shall send a written notice at least sixty (60) days in advance of each formal meeting to each voting member. A longer notification period is recommended. It is anticipated that the continuing close coordination of the participants, the decision at the prior formal meeting, and publication of a meeting notice in FORTH Dimensions and other trade journals will provide sufficient notice to the FORTH community.
2.1.4 At a formal FST meeting, there shall be general sessions consisting of all attendees. General sessions are for matters that are ready for discussion and decision. All votes concerning the Standard, Charter, or FST procedures must take place during a general session.
2.1.5 Also at formal meetings, subteams will be established to examine groups of proposals and to prepare recommendations for a general session. All meeting attendees may participate in the work and voting of a subteam. Each subteam should elect from its members a coordinator to conduct its meetings and a reporter to record and report its recommendations.
2.1.6 The Chairperson may publish and distribute an agenda at or in advance of a formal meeting. As a guideline, each day of a formal meeting begins with a general session, followed by concurrent subteam meetings followed by another general session.
2.1.7 In view of the voluntary nature of the FST, at least one third of the membership is required to hold a formal meeting. Two thirds of the number of voting members present at the start of each day's first general session shall set the quorum for the remainder of that day. 76
2.1.8 Between formal meetings, the Chairperson may appoint such informal working groups as is appropriate. Each group may be given a goal and scope to direct its activities. Its conclusions or recommendations must be given to the Chairperson in written form.
2.2.1 Prior to each formal meeting, the Chairperson may solicit submission of comments and proposals for changes, additions, or deletions to the then-current Standard, the draft Standard or this Charter. A cutoff date may be specified for the submission of such proposals.
2.2.2 A considerable amount of information must accompany each proposal to help FST members analyze the proposal. Therefore, submission of proposals and comments shall be according to the format and instructions shown in the "Proposal/Comment Form" included as an Appendix to this Standard. Any proposal not in the appropriate form or received after the cutoff date may not be considered unless the Chairperson deems it to be of sufficient significance.
2.2.3 Unsolicited proposals and comments by volunteers are acknowledged as valuable. Any individual or group may submit proposals and/or comments concerning the Standard or this Charter. These should be sent to the official address of the FST. Properly formatted proposals and comments are preferred. The author or a representative should plan to attend the next formal meeting to emphasize, support, and possibly modify the proposals.
2.2.4 Since the quantity of proposals and comments may exceed the number for which there is time to be voted upon, submission of a proposal does not automatically mean that it will be voted upon at the next formal FST meeting. The Chairperson or some members appointed by the Chairperson or elected by the voting members may screen and organize the received proposals and comments for voting upon at the next formal meeting.
2.2.5 To allow reflection and examination, proposals and comments shall be distributed to FST voting members and sponsors in advance of a formal meeting. Proposals and comments not distributed in advance, including proposals made during a formal meeting, may be considered at the discretion of the Chairperson. 77
After a formal meeting, the referees and officers of the FST shall prepare a draft Standard for review by the then- current FST voting members. The referees and officers shall consolidate proposals accepted by vote during the meeting, resolve any ambiguities or problems, and incorporate these changes with the text of the previous Standard or draft Standard.
2.4.1 The referees and officers may, by near unanimous decision (not more than one no vote), declare the draft Standard, as mentioned in the previous paragraph, as being the proposed Standard.
2.4.2 A proposed Standard shall be distributed to all FST voting members for a mail ballot. This ballot shall be based solely on the text of the proposed Standard as distributed.
2.4.3 Each ballot returned shall be signed by the voting member submitting it. An affirmative vote of at least two thirds of the voting members shall adopt the document. Such adoption makes the draft Standard the current, official FST Standard which supersedes all prior Standards.
2.5.1 At a formal FST meeting, the charter may be amended by a simple majority of voting members present provided that at least one third of all voting members are present; such amendments become effective at the end of the current formal meeting.
2.5.2 At other than a formal FST meeting, the charter may be amended by a simple majority of all voting members, such vote to be taken by signed mail ballots. 78
Membership in the FST is a privilege, not a right. An invitation for voting membership may be extended to those who the FST feels can contribute to the goals of the Standard and the FST. There are several classes of participation in the efforts of the FST. Membership in each class has no specified term but continues from the time when membership is initiated to the conclusion of the next formal meeting.
3.2.1 Voting members are individuals who are elected into such membership at the concluding session of a formal FST meeting. Any voting member who resigns between formal meetings shall not be replaced until the membership elections at the conclusion of the next formal meeting. A newly elected voting member gains voting rights only after all voting members have been elected. A significant professional FORTH background is required of voting members.
3.2.2 Each voting member present at a formal meeting shall indicate in writing his or her desire to continue as a voting member. Only these voting members can vote in a general session of a formal meeting on any matters affecting the Standard or the Charter and on the election of all voting members.
3.2.3 Voting members are elected by a simple majority of those voting members present. The number of voting members shall be limited to thirty (30). Individuals eligible to be elected are selected from each of the following ordered categories in order, until the number of voting members reaches the limit. 3.2.3.1 Category 1: current voting member who have actively participated in at least two days of a formal meeting. Voting members are expected to actively participate in subteam meetings and all general sessions. 3.2.3.2 Category 2: current voting members who are not eligible by Category 1, but who have requested in writing that his or her voting membership be maintained. 3.2.3.3 Category 3: eligible candidates. Eligible candidates will be presented to the voting members then elected as follows: 79 3.2.3.3.1 If the number of eligible candidates does not exceed the number of openings for voting membership, each candidate is voted upon and accepted by a simple majority. 3.2.3.3.2 If the number of eligible candidates does exceed the number of openings for voting membership, candidates will be voted upon by ballot whereby each voting member may vote for up to the number of openings remaining. Those candidates receiving the most votes will be elected until there are no more openings for voting membership.
3.3.1 Candidates are individuals who desire to actively participate in and support the FST by becoming voting members.
3.3.2 To be eligible, each Candidate must: declare in writing to the secretary at the first general session of a formal FST meeting that he or she is a Candidate, actively participate in subteam meetings and all general sessions at a formal FST meeting, and have a significant professional background in FORTH. The Chairperson may request information or ask questions of any candidate to determine his or her technical knowledge and experience. Candidates are expected to submit proposals, participate in the discussions of the formal meeting, and contribute to the work and voting of subteams.
3.4.1 Observers are individuals who attend a formal meeting but are neither voting members nor candidates. At the discretion of the Chairperson, they may contribute to the discussion at general sessions and to the work of subteams. The number of observers allowed at a formal meeting may be limited by the Chairperson.
3.5.1 FST sponsors are individuals or organizations who contribute funds and other assistance to aid the work of the FST. FST sponsors have no duties or responsibilities in the FST, but they will receive copies of proposals and comments considered at a formal meeting, and drafts and adopted standards prepared as a result of that meeting. 80
3.5.2 FST sponsorship exists from the end of one formal meeting to the end of the next formal meeting.
3.5.3 Qualification of FST sponsors may be determined by a simple majority vote at a formal FST meeting. If no such qualification exist, the Chairperson may specify qualifications, including the amount of financial contributions, which will remain in effect until the next formal FST meeting.
There shall be four types of elected officers of the FST: the Chairperson, the Secretary, the Treasurer, and one or more Referees. Each officer shall be elected at a formal meeting of the FST and serve until the next formal meeting.
If any office other than the Chairperson becomes vacant between formal meetings, the Chairperson may appoint a replacement. If the office of the Chairperson becomes vacant between formal meetings, a new Chairperson shall be elected by an informal majority vote of the remaining officers. At any formal meeting, any officer, including the Chairperson, may be replaced by a simple majority vote of the voting members present at that meeting.
4.3.1 The Chairperson is responsible for governing the general business of the FST. He or she is responsible for implementing the FST's Charter and any other requirements specified by the Standard.
4.3.2 The Chairperson's term of office shall be from the conclusion of the formal meeting at which he or she is elected to the conclusion of the next formal meeting. The election of a Chairperson is held at the concluding general session of a formal meeting after the election of voting members; hence, newly elected voting members may vote for the Chairperson. Only voting members are eligible to be elected Chairperson.
4.3.3 The Chairperson shall conduct each formal meeting. In general, the meetings will follow the current Robert's Rules of Order; however, the Chairperson may determine the specific rules for a formal meeting. 81
4.3.4 Any matter needing a decision between formal meetings not specified by this Charter shall be decided by the Chairperson.
4.3.5 The Chairperson has duties and responsibilities specified elsewhere in this Charter.
4.4.1 The Secretary is responsible for recording the activities and results of the FST.
4.4.2 The Secretary is elected at the first general session of a formal meeting and serves until a Secretary is elected at the beginning of the next formal meeting.
4.4.3 The Secretary has many responsibilities.
4.4.3.1 The Secretary is responsible for collecting, maintaining, and archiving the official copies of the Standard, the Charter, all other FST documents, correspondence, and lists of the FST members of each class.
4.4.3.2 During a formal meeting, the Secretary is responsible for:
4.4.3.3 The Secretary is also responsible for collecting, archiving, and distributing proposals before a formal meeting. He or she is also responsible for incorporating proposals accepted during a formal meeting into the Standard or Charter. Other officers aid the Secretary in these duties.
4.5.1 The Treasurer is responsible for managing the financial business of the FST. He or she is responsible for maintaining accurate and current financial records and for accepting and dispersing funds for official FST activities. 82
4.5.2 The Treasurer's term of office shall be from the conclusion of the formal meeting at which he or she is elected to the conclusion of the next formal meeting. The election of a Treasurer is held just after the election of the Chairperson. Only voting members are eligible to be elected Treasurer.
4.6.1 At the conclusion of a formal meeting there may be additional technical work required to prepare a draft Standard or Charter. This work shall be performed by the officers of the FST, including a group of Referees. They should be individuals who have superior knowledge and experience in the implementation and use of FORTH.
4.6.2 At least three and no more than five Referees shall be elected by a majority of the voting members present at the concluding general sessions of a formal meeting. This takes place after the election of voting members. A Referee's term is from election at the end of one formal meeting until the end of the next formal meeting. Only voting members are eligible to be elected as Referees.
4.6.3 The Referees shall adopt methods and rules as they deem appropriate to complete their work; they may be informal. However, any matter committed to the Referees for resolution must achieve near unanimous agreement (not more than one no vote). Lacking that, the matter shall be omitted from further action pending further consideration at the next formal meeting.
5.1.1 Since FORTH is an extensible language and subject to evolution, the Standard may contain a section describing experimental proposal to aid in the analysis of and the decision for or against future adoption into the Standard. After the results of experimentation are known, each proposal will be considered, at a future formal meeting, for inclusion into the Standard.
5.1.2 An experimental proposal may be individual FORTH words, sets of related words, or specifications for part of the Standard. Experimental proposals may be derived from ordinary proposals or other contributions. 83
Each experimental proposal must contain the following minimum information:
5.2.1 A description of the proposal including an overview of its functions and its interactions with existing FORTH words.
5.2.2 A glossary entry of each word in the form and notation of the Standard.
5.2.3 A statement by the author(s) indicating why the proposal meets inclusion into the Standard. Both advantages and disadvantages should be discussed.
It is suggested that each experimental proposal also include:
5.3.1 A source definition for each word in the proposal. High level definitions using Standard words are preferred, but new primitive words may be defined in an assembly language of one commonly-known processor. Sufficient documentation should be provided so that implementation on other processors is direct.
5.3.2 An example showing usage of the new words.
Only voting members have the right to vote on proposals affecting the Standard, a draft Standard, or this Charter.
At the discretion of the Chairperson, advisory votes may be requested at a formal meeting. At the discretion of the Chairperson, all attendees may participate in an advisory vote.
Any vote at a formal meeting may be by show of hands or, at the discretion of the Chairperson, by an informal secret paper ballot or a roll call. 84
A vote to adopt a proposal into the draft Standard or to change the Standard, except for the Experimental Proposals section of the Standard requires a two-thirds affirmative vote of the voting members present at a general session of a formal meeting, provided that the number of votes cast are at least two thirds of that morning's quorum count. To adopt an experimental proposal into the Experimental Proposals section of the draft Standard or to change this Charter, an affirmative vote of a simple majority is required. Accepting any other procedural matter at a formal meeting requires only a simple majority affirmative vote.
All votes must be cast by the particular voting member eligible to vote. No proxy voting is allowed. 85
The following pages are the proposal and/or comment submittal form. The form includes instructions which should be explanatory. Copies of submitted proposals and comments will be made available to FORTH Standards Team members and to team sponsors. 86
FST Proposal and Comment Submittal Form ----------------------------------------------------------------- FST USER Title: Proposal Number: ONLY --> Related Proposals: Disposition: ================================================================= Keyword(s): Category: ( ) Proposal or ( ) Comment FORTH Word(s): Section #(s): ----------------------------------------------------------------- Abstract: ----------------------------------------------------------------- Proposal and Discussion: ---------------------------------------------------------------- Submitted by: Date: Page of ================================================================= FORTH Standards Team; PO Box 4545; Mountain View, CA 94040 820801
Please use the supplied forms for your entire proposal. The continuation form is only to be used if absolutely necessary; try to get your proposal to fit on the first sheet. If it helps, use a reducing copy machine to get more material onto the first sheet. If you must use multiple sheets, put the main idea onto the first sheet and less important material onto continuation sheets. Remember that material on continuation sheets may be overlooked.
The proposal forms have been produced on a computer system so that you may produce your proposals using your own computer system. If you print your proposal and form on your computer system, all of the information shown on the form(s) MUST be printed and in the same location.
The following are the instructions for each of the areas of the form:
FST Proposal and Comment Submittal Continuation Form ----------------------------------------------------------------- FST USE ONLY --> Proposal Number: ================================================================= ----------------------------------------------------------------- Submitted by: Date: Page of ================================================================= FORTH Standards Team; PO Box 4545; Mountain View, CA 94040 820801