13 The optional Locals word set

13.1 Introduction

13.2 Additional terms and notation

None.

13.3 Additional usage requirements

13.3.1 Locals

A local is a data object whose execution semantics shall return its value, whose scope shall be limited to the definition in which it is declared, and whose use in a definition shall not preclude reentrancy or recursion.

13.3.2 Environmental queries

Append table 13.1 to table 3.4.

See: 3.2.6 Environmental queries.

Table 13.1: Environmental Query Strings

String Value data type Constant? Meaning

#LOCALS n yes maximum number of local variables in a definition

13.3.3 Processing locals

To support the locals word set, a system shall provide a mechanism to receive the messages defined by (LOCAL) and respond as described here.

During the compilation of a definition after : (colon), :NONAME, or DOES>, a program may begin sending local identifier messages to the system. The process shall begin when the first message is sent. The process shall end when the "last local" message is sent. The system shall keep track of the names, order, and number of identifiers contained in the complete sequence.

13.3.3.1 Compilation semantics

The system, upon receipt of a sequence of local-identifier messages, shall take the following actions at compile time:
  1. Create temporary dictionary entries for each of the identifiers passed to (LOCAL), such that each identifier will behave as a local. These temporary dictionary entries shall vanish at the end of the definition, denoted by ; (semicolon), ;CODE, or DOES>. The system need not maintain these identifiers in the same way it does other dictionary entries as long as they can be found by normal dictionary searching processes. Furthermore, if the Search-Order word set is present, local identifiers shall always be searched before any of the word lists in any definable search order, and none of the Search-Order words shall change the locals' privileged position in the search order. Local identifiers may reside in mass storage.

  2. For each identifier passed to (LOCAL), the system shall generate an appropriate code sequence that does the following at execution time:

    1. Allocate a storage resource adequate to contain the value of a local. The storage shall be allocated in a way that does not preclude re-entrancy or recursion in the definition using the local.

    2. Initialize the value using the top item on the data stack. If more than one local is declared, the top item on the stack shall be moved into the first local identified, the next item shall be moved into the second, and so on.

    The storage resource may be the return stack or may be implemented in other ways, such as in registers. The storage resource shall not be the data stack. Use of locals shall not restrict use of the data stack before or after the point of declaration.

  3. Arrange that any of the legitimate methods of terminating execution of a definition, specifically ; (semicolon), ;CODE, DOES> or EXIT, will release the storage resource allocated for the locals, if any, declared in that definition. ABORT shall release all local storage resources, and CATCH / THROW (if implemented) shall release such resources for all definitions whose execution is being terminated.

  4. Separate sets of locals may be declared in defining words before DOES> for use by the defining word, and after DOES> for use by the word defined.

A system implementing the Locals word set shall support the declaration of at least sixteen locals in a definition.

13.3.3.2 Syntax restrictions

Immediate words in a program may use (LOCAL) to implement syntaxes for local declarations with the following restrictions:

  1. A program shall not compile any executable code into the current definition between the time (LOCAL) is executed to identify the first local for that definition and the time of sending the single required "last local" message;

  2. The position in program source at which the sequence of (LOCAL) messages is sent, referred to here as the point at which locals are declared, shall not lie within the scope of any control structure;

  3. Locals shall not be declared until values previously placed on the return stack within the definition have been removed;

  4. After a definition's locals have been declared, a program may place data on the return stack. However, if this is done, locals shall not be accessed until those values have been removed from the return stack;

  5. Words that return execution tokens, such as ' (tick), ['], or FIND, shall not be used with local names;

  6. A program that declares more than sixteen locals in a single definition has an environmental dependency;

  7. Locals may be accessed or updated within control structures, including do-loops;

  8. Local names shall not be referenced by POSTPONE and [COMPILE].

See: 3.4 The Forth text interpreter.

13.4 Additional documentation requirements

13.4.1 System documentation

13.4.1.1 Implementation-defined options

13.4.1.2 Ambiguous conditions

  • executing a named local while in interpretation state (13.6.1.0086 (LOCAL));
  • a local name ends in ":", "[", "^";
  • a local name is a single non-alphabetic character;
  • the text between {: and :} extends over more than one line;
  • {: ... :} is used more than once in a word.

13.4.1.3 Other system documentation

  • no additional requirements.

13.4.2 Program documentation

13.4.2.1 Environmental dependencies

13.4.2.2 Other program documentation

  • no additional requirements.

13.5 Compliance and labeling

13.5.1 Forth-2012 systems

The phrase "Providing the Locals word set" shall be appended to the label of any Standard System that provides all of the Locals word set.

The phrase "Providing name(s) from the Locals Extensions word set" shall be appended to the label of any Standard System that provides portions of the Locals Extensions word set.

The phrase "Providing the Locals Extensions word set" shall be appended to the label of any Standard System that provides all of the Locals and Locals Extensions word sets.

13.5.2 Forth-2012 programs

The phrase "Requiring the Locals word set" shall be appended to the label of Standard Programs that require the system to provide the Locals word set.

The phrase "Requiring name(s) from the Locals Extensions word set" shall be appended to the label of Standard Programs that require the system to provide portions of the Locals Extensions word set.

The phrase "Requiring the Locals Extensions word set" shall be appended to the label of Standard Programs that require the system to provide all of the Locals and Locals Extensions word sets.

13.6 Glossary

13.6.1 Locals words

13.6.2 Locals extension words

ContributeContributions

ruvavatar of ruv Recognizer for localsComment2020-06-10 02:47:06

May a local be unfindable via FIND in a standard Forth system?

The answer is not stated explicitly. But the consequence of other clauses is that yes, it may:

  1. Locals should be searched before the search order.
  2. FIND (as well as FIND-NAME) considers the search order only (if it's present).
  3. A system is not obligated to use FIND for finding definition names in the Forth text interpreter.

So, it means even more: FIND cannot find locals in a standard Forth system that provides the optional Search-Order word set.

In any case, the result is that the locals may be recognized by a recognizer before other Forth definitions.


What does the following phrase mean: "The system need not maintain these identifiers in the same way it does other dictionary entries as long as they can be found by normal dictionary searching processes" ? Does "they" refer to "other dictionary entries" or to "these identifiers"?

AntonErtlavatar of AntonErtl

The existence of the sentence "The system need not maintain ..." only makes sense if "they" refers to the locals. The other dictionary entries can be found with the normal dictionary searching processes anyway, so the sentence would be redundant if "they" referred to the other dictionary entries.

Two arguments for requiring that FIND-NAME/FIND find locals:

  1. FIND-NAME/FIND are "normal dictionary searching processes", so these words should find the locals according to that sentence.

  2. The intent of the Forth-94 committee (and also my intent when proposing FIND-NAME) was that it is possible to write a user-defined text interpreter, as outlined in the rationale for COMPILE,. There is no other standard way to find locals, so FIND and FIND-NAME should include this functionality.

An argument against:

  1. We did not mention locals in the specifications of FIND and FIND-NAME. But given the intent, that was an oversight, certainly on my part.

Looking at what existing systems do, I wrote the small test

: x c" fluffystunk" ; : foo locals| fluffystunk | [ x find cr .s 2drop ] ;

In VFX and Gforth, FIND finds fluffystunk; in SwiftForth, iForth, and lxf, FIND does not.

Apparently this has not been an issue for 26 years, so apparently nobody has used a user-defined text interpreter to process a program using locals on SwiftForth, iForth, or lxf; nor has anybody written a program that relies on FIND not finding locals, and let it run on VFX or Gforth. Still, I think that the standard should nail this issue down.

ruvavatar of ruv

Two arguments for requiring that FIND-NAME/FIND find locals

As I can see, we have some arguments not for requiring, but for allowing.

  1. I agree that "they" refers to identifiers of the locals. But it seems to me, "as long as they can be found" means that the corresponding statement is only applicable when locals "can be found by normal dictionary searching processes". It does not require that they should be found by "normal dictionary searching processes". OTOH, what is "normal dictionary searching processes"? And do we have non normal dictionary searching processes? This wording too fuzzy to produce strong arguments.

  2. Actually, there is no any standard way to find locals, despite the intention. So, I suggest to introduce such a way via recognizer.

Concerning FIND. I think, when the Search-Order word set is provided, we can allow FIND-NAME to find locals only via the search order (i.e., when they are implemented as some special word list that is appended to the top of search order). Otherwise, FIND-NAME cannot be implemented via TRAVARSE-WORDLIST. Also, some existent implementation become nonstandard.

So, we should allow, but should not require this approach.

I think, we should provide a recognizer for locals, that will works in any case.

ruvavatar of ruv

Correction: Otherwise (i.e., if FIND-NAME is required to search locals and allowed to do it beyond the search order), the function of FIND-NAME cannot be implemented via GET-ORDER and TRAVARSE-WORDLIST.

Reply New Version