Eliminating of some ambiguous conditions

[ruv]

A list of ambiguous conditions that are considered as candidates to convert them into an unambiguous exceptions with assigned throw codes (see also #1) should be developed.

Note: the corresponding new test cases should be also added, if possible.

The list of ambiguous condition is provided in the section 4.1.2 Ambiguous conditions.

The list below is under construction, it will be updated right here.

Mandatory

• specify behavior for 17.6.1.0245 /STRING when n > u1 (an implicit ambiguous condition exists at the moment);
  • possible options:
    • throw an exception;
    • make u2 zero;
    • change wording;
  • see also contribution 352 on forth-standard.org;
• An ambiguous condition exists if ud overflows during the conversion (6.1.0570 >NUMBER);
  • see also 4.1.2 Ambiguous conditions / "producing a result out of range";
  • possible options:
    • throw -11 "result out of range" (then >number must be execute by catch in recognizers);
    • stop on the digit that produces overflow (it is allowed due to the ambiguous condition);
• a name is not found and not a number;
  • throw code -13 "undefined word";
  • todo: a lexeme it not recognized;
  • it should be integrated into 3.4.2 Finding definition names, to avoid repeating it in many glossary entries (?);
• a definition name too long (6.1.0450 :, 15.6.2.2264 SYNONYM, and other defining words);
  • throw code -19 "definition name too long";
• a parsed lexeme does not fit a transient region (6.1.2450 WORD, see also 3.3.3.6 Other transient regions, 4.1.2 Ambiguous conditions: "string longer than a counted string returned by 6.1.2450 WORD");
  • possible throw codes
    • -18 "parsed string overflow";
    • -19 "definition name too long";
    • introduce a new throw code;
• an empty lexeme is encountered unexpectedly (6.1.0895 CHAR, 6.1.2033 POSTPONE, 11.6.2.1714 INCLUDE, and other parsing words; see also 4.1.2 Ambiguous conditions: "unexpected end of input buffer, resulting in an attempt to use a zero-length string as a name");
  • throw code -16 "attempt to use zero-length string as a name";
  • see also a discussion about char — the word char shall not return a random character or a delimiter;
• unexpected end of the input buffer (6.1.2165 S", 6.2.2266 S\", 6.2.0200 .(, 6.1.0080 ();
  • a new throw code should be introduced;
  • NB: currently, due to an ambiguous condition, the standard allows s" to parse multi-line string literal; if the standard will require to unconditionally throw an exception in such a case, parsing multi-line string literal will be non-standard. A possible solution (if a quotation mark is not found in the parse area): require to either parse multi-line string, or throw an exception.
• the search order is empty in 16.6.2.0715 ALSO, 16.6.2.2037 PREVIOUS, 16.6.1.1180 DEFINITIONS, 16.6.2.1590 FORTH;
  • throw code -50 "search-order underflow";
  • see also:
    • 16.4.1.2 Ambiguous conditions / "search order empty";
• an I/O exception occurs reading the file, or an I/O exception occurs while closing the file (11.6.1.1718 INCLUDED, 11.6.1.1717 INCLUDE-FILE);
  • throw code -37 "file I/O exception";
  • possible throw code -70 "READ-FILE";
  • possible throw code -71 "READ-LINE";
  • possible throw code -62 "CLOSE-FILE";
• a named file can not be opened (11.6.1.1718 INCLUDED);
  • possible throw code -38 "non-existent file";
  • distinguish non-existent file (ior code -38) and access denied (a new ior should be introduced);
• A deferred word is not set with an execution token;
  • a new throw code should be introduced;

Implicit ambiguous conditions that should be eliminated

These ambiguous conditions are not mentioned explicitly.

• A line does not fit the input buffer (in INCLUDE-FILE, INCLUDED, etc);
  • lines of at least 128 characters shall be supported (according to 11.3.5 Parsing);
  • a new throw code should be introduced;
• An implicit ambiguous condition exists if empty-buffers is executed when loading of some block buffer is not completed;
  • see also:
    • discussion in ForthHub;
    • contribution 359 at forth-standard.
  • a possible solution: do not unassign buffers whose interpretation has been started but not completed;
    • see also New requirements for the input buffer;
• insufficient space in the dictionary (in ALLOT, , (Comma), C, (C-comma));
  • throw code -8 "dictionary overflow";

Feasible

• the search order is overflow in 16.6.2.0715 ALSO, 16.6.1.2197 SET-ORDER;
  • throw code -49 "search-order overflow";
  • see also:
    • 16.4.1.1 Implementation-defined options / "maximum number of word lists in the search order";
    • Table 16.2: Environmental Query Strings / "maximum number of word lists usable in the search order";
    • 16.4.1.2 Ambiguous conditions / "too many word lists in search order";
• a new word list cannot be created by 16.6.1.2460 WORDLIST;
  • if the dictionary overflow, the throw code: -8 "dictionary overflow" shall be thrown;
  • see also:
    - Table 16.2: Environmental Query Strings;
• insufficient space in the dictionary (during code generation);
  • introduce a new throw code, something like "code space overflow";
  • or use throw code -8 "dictionary overflow";
• "if u (block number) is zero" (7.6.1.1790 LOAD).
  • throw code -35 "invalid block number";
• "if u is not an available block number" (7.6.1.0820 BUFFER, 7.6.1.0800 BLOCK, 7.6.2.1770 LIST, 7.6.1.1790 LOAD);
  • throw code -35 "invalid block number";
• exponent too big (or too small) for conversion (12.6.2.1203 DF!, 12.6.2.1204 DF@, 12.6.2.2202 SF!, 12.6.1.1400 F!, 12.6.1.1470 F>D) — in 12.4.1.2 Ambiguous conditions;
• string larger than pictured-numeric output area (12.6.2.1427 F., 12.6.2.1513 FE., 12.6.2.1613 FS.) — in 12.4.1.2 Ambiguous conditions;

Optional

• "if deallocated memory contains definitions" (3.3.3.2 Contiguous regions, 6.1.0710 ALLOT);
  • a new throw code should be introduced;
• BASE is not decimal (12.6.1.2143 REPRESENT, 12.6.2.1427 F., 12.6.2.1513 FE., 12.6.2.1613 FS.) — in 12.4.1.2 Ambiguous conditions;
  • there are three options:
    • throw an exception;
    • perform output according to BASE, and also use it as the base of exponent (could be useful for debug);
    • perform output as if BASE is decimal, regardless of the actual BASE (seems undesirable and inconsistent with other output methods);

Difficult to implement

• "if definitions or data required for correct execution of the program are removed during execution of name"
  (6.2.1850 MARKER, 15.6.2.1580 FORGET);
  • see also a comment concerning an omission;