Fix incorrect IETF RFC 2119 keywords

Author: python-processing-unit

docs/specification/0-toc-and-preamble.html

@@ -17,7 +17,7 @@
 
 ## 1. Preamble
 
-The key words "MUST", "MUST not", "REQUIRED", "SHALL", "SHALL not", "SHOULD", "SHOULD not", "RECOMMENDED",  "MAY", and "OPTIONAL" in this document are to be interpreted as described in [IETF RFC 2119](https://datatracker.ietf.org/doc/html/rfc2119), as clarified in [IETF RFC 8174](https://datatracker.ietf.org/doc/html/rfc8174).
+The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this document are to be interpreted as described in [IETF RFC 2119](https://datatracker.ietf.org/doc/html/rfc2119), as clarified in [IETF RFC 8174](https://datatracker.ietf.org/doc/html/rfc8174).
 
 Prefix is a statically typed, imperative, interpreted programming language focused on explicit, readable source code.
 

docs/specification/2-lexical-structure.html

@@ -17,7 +17,7 @@
 
 ## 2. Lexical structure
 
-Source files MUST consist of ASCII characters. Non-ASCII characters MUST not appear in syntactic elements that enter the program namespace, such as identifiers.
+Source files MUST consist of ASCII characters. Non-ASCII characters MUST NOT appear in syntactic elements that enter the program namespace, such as identifiers.
 
 ---
 
@@ -35,29 +35,29 @@
 
 ### 2.2 Tokens and reserved words
 
-The lexer MUST distinguish at least the following token classes: numeric literals, string literals, identifiers, keywords and built-ins, and delimiters. The base delimiters of the language are `(`, `)`, `{`, `}`, `[`, `]`, `<`, `>`, `,`, `:`, `=`, and `~`. The pointer marker `@` MUST be tokenized separately and MUST not be treated as part of an identifier.
+The lexer MUST distinguish at least the following token classes: numeric literals, string literals, identifiers, keywords and built-ins, and delimiters. The base delimiters of the language are `(`, `)`, `{`, `}`, `[`, `]`, `<`, `>`, `,`, `:`, `=`, and `~`. The pointer marker `@` MUST be tokenized separately and MUST NOT be treated as part of an identifier.
 
 Keywords and built-in names MUST be matched case-sensitively and MUST be written in their canonical uppercase forms. If a reserved word is written in any other case, it MUST be tokenized as an identifier instead.
 
 The character `-` MUST introduce a negative numeric literal when it is followed, optionally after horizontal whitespace, by a `0`-prefixed numeric base marker. The exact spelling `-INF` MUST remain reserved for negative infinity, and the exact spelling `-NaN` MUST remain invalid. In all other cases, `-` MAY participate in identifiers subject to [2.3](#23-identifiers).
 
-The character `~` MUST be reserved for coerced function parameters and MUST not appear inside identifiers.
+The character `~` MUST be reserved for coerced function parameters and MUST NOT appear inside identifiers.
 
 ---
 
 ### 2.3 Identifiers
 
-Identifiers MUST be non-empty and case-sensitive. Variables and user-defined functions share a single flat namespace, so one name MUST not denote both a variable and a function. A user-defined function name MUST not conflict with any built-in operator or function name.
+Identifiers MUST be non-empty and case-sensitive. Variables and user-defined functions share a single flat namespace, so one name MUST NOT denote both a variable and a function. A user-defined function name MUST NOT conflict with any built-in operator or function name.
 
-Identifiers MUST not contain non-ASCII characters or any of the following characters: `{`, `}`, `[`, `]`, `(`, `)`, `=`, `,`, `!`, `~`, or `@`. The first character of an identifier MUST not be a decimal digit (`0`-`9`), and the first two characters of an identifier MUST not be `-0`.
+Identifiers MUST NOT contain non-ASCII characters or any of the following characters: `{`, `}`, `[`, `]`, `(`, `)`, `=`, `,`, `!`, `~`, or `@`. The first character of an identifier MUST NOT be a decimal digit (`0`-`9`), and the first two characters of an identifier MUST NOT be `-0`.
 
 The first identifier character MAY be a letter `A-Z` or `a-z`, `*`, or one of `/`, `$`, `%`, `&`, `_`, `+`, `|`, `?`, or `-`. If the first identifier character is `-`, the second character MUST be valid as an opening character. Subsequent identifier characters MAY additionally include the decimal digits `0-9`, `*`, and `-`. The exact spelling `-INF` is reserved by [4.3.2](#4-types.html#432-special-values). This permissive ASCII-only character set preserves an unambiguous distinction between identifiers and numeric literals, which MUST begin with a decimal digit.
 
 ---
 
 ### 2.4 Pointer token
 
-The syntax `@name` MUST form a pointer literal, where `@` is a dedicated lexical token and `name` is an identifier resolved in the current lexical environment. Because `@` is a separate token, it MUST not appear inside identifier names.
+The syntax `@name` MUST form a pointer literal, where `@` is a dedicated lexical token and `name` is an identifier resolved in the current lexical environment. Because `@` is a separate token, it MUST NOT appear inside identifier names.
 
 ---
 

docs/specification/3-statements.html

@@ -69,15 +69,15 @@
 
 In the parameterized form, `catch(SYMBOL name)` MUST create a temporary `str` binding named `name` in the handler's lexical environment containing the triggering error message. That temporary binding MUST shadow any existing binding of the same name only for the duration of the `catch` block.
 
-`try` and `catch` MUST intercept interpreter-level errors. Errors raised inside `async` or other background execution contexts MUST be reported through the runtime's error-reporting mechanisms and MUST not synchronously transfer control to a surrounding `catch` block in another thread.
+`try` and `catch` MUST intercept interpreter-level errors. Errors raised inside `async` or other background execution contexts MUST be reported through the runtime's error-reporting mechanisms and MUST NOT synchronously transfer control to a surrounding `catch` block in another thread.
 
 ---
 
 ### 3.5 Loops
 
 `while(condition){ ... }` MUST repeatedly evaluate its condition before each iteration and MUST terminate when the condition becomes false.
 
-`for(counter, target){ ... }` MUST evaluate `target` exactly once at loop entry, require that value to be an `int`, initialize `counter` to `1`, and execute the body once for each value through `target`, inclusive. The loop counter MUST be loop-local and MUST not persist after the loop finishes, though other symbols declared in the body remain bound in the enclosing environment.
+`for(counter, target){ ... }` MUST evaluate `target` exactly once at loop entry, require that value to be an `int`, initialize `counter` to `1`, and execute the body once for each value through `target`, inclusive. The loop counter MUST be loop-local and MUST NOT persist after the loop finishes, though other symbols declared in the body remain bound in the enclosing environment.
 
 `parfor(counter, target){ ... }` MUST evaluate `target` once, require an `int`, then execute the iterations `1..target` concurrently. The interpreter MUST wait for all iterations to finish before continuing. The loop counter is iteration-local and does not persist afterward, while other symbols declared in iteration bodies are merged back into the enclosing environment. Concurrent writes to shared identifiers are therefore race-prone, and the resulting value is implementation-defined.
 
@@ -93,7 +93,7 @@
 
 The statement form `thread(symbol){ ... }` MUST create a background task and bind its handle to `symbol` with static type `thread` in the current environment.
 
-Runtime errors raised inside asynchronous execution MUST be recorded by the interpreter's error-reporting and state-logging mechanisms and MUST not synchronously abort the main thread.
+Runtime errors raised inside asynchronous execution MUST be recorded by the interpreter's error-reporting and state-logging mechanisms and MUST NOT synchronously abort the main thread.
 
 ---
 

docs/specification/4-types.html

@@ -115,7 +115,7 @@
 
 An `int` literal that begins with a decimal digit (`0`-`9`) and does not include a base prefix MUST be evaluated as a decimal (base-10) literal. A numeric literal that begins with a decimal digit and includes a base prefix (that is, one or more digits precede the base prefix) MUST raise an error.
 
-`int` literals MUST support negative values via prefixing with a `-` before the base prefix, and positive values with no sign. `int` literals MUST not support a `+` prefix.
+`int` literals MUST support negative values via prefixing with a `-` before the base prefix, and positive values with no sign. `int` literals MUST NOT support a `+` prefix.
 
 Literal digits MUST match the selected base's alphabet. Bases smaller than 2 or larger than 64 MUST raise an error.
 
@@ -141,7 +141,7 @@
 
 `float` literals MUST consist of an integer part (preceded by the base prefix, if present), a radix point (`.`), and a fractional part. The integer and fractional parts MUST each contain at least one digit in the selected base.
 
-`float` literals MUST support negative values via prefixing with a `-` before the base prefix, and positive values with no sign. `float` literals MUST not support a `+` prefix.
+`float` literals MUST support negative values via prefixing with a `-` before the base prefix, and positive values with no sign. `float` literals MUST NOT support a `+` prefix.
 
 ---
 
@@ -151,9 +151,9 @@
 
 - `INF` - Infinity. `INF` MUST support negative values via prefixing with a `-` (`-INF`).
 
-- `NaN` - Quiet Not a Number. `NaN` MUST not support negative values. Attempting to create a negative `NaN` MUST cause an error.
+- `NaN` - Quiet Not a Number. `NaN` MUST NOT support negative values. Attempting to create a negative `NaN` MUST cause an error.
 
-`INF`, `-INF`, and `NaN` MUST not include a base prefix and are considered base-NaN.
+`INF`, `-INF`, and `NaN` MUST NOT include a base prefix and are considered base-NaN.
 
 When numeric values are converted to `str`, they MUST render in their own base and MUST include the base prefix. `INF`, `-INF`, and `NaN` render without a base prefix.
 
@@ -177,7 +177,7 @@
 
 `tensor` literals MUST be enclosed in square brackets (`[` and `]`). Each pair of matching brackets MUST introduce a dimension, and nested brackets MUST form a rectangular shape where all sublists at a given depth have the same length. A `tensor` literal that mixes sub-brackets of differing lengths MUST raise a syntax error.
 
-If an element evaluates to a `tensor` value, it MUST occupy a single position and MUST not contribute additional dimensions to the shape.
+If an element evaluates to a `tensor` value, it MUST occupy a single position and MUST NOT contribute additional dimensions to the shape.
 
 ---
 
@@ -211,7 +211,7 @@
 
 #### 4.5.2 Map indexing
 
-`map` indexing MUST use angle brackets (`<` and `>`) with a comma-separated list of keys. Each key MUST evaluate to a scalar value of type `int`, `float`, or `str`. Tensor values MUST not be permitted as keys. The number of keys supplied MAY vary between lookups.
+`map` indexing MUST use angle brackets (`<` and `>`) with a comma-separated list of keys. Each key MUST evaluate to a scalar value of type `int`, `float`, or `str`. Tensor values MUST NOT be permitted as keys. The number of keys supplied MAY vary between lookups.
 
 Looking up a key that does not exist MUST raise a runtime error.
 

docs/specification/5-namespaces-and-symbols.html

@@ -23,7 +23,7 @@
 
 ### 5.1 Declarations, bindings, and lifetime
 
-A declaration MUST record the symbol's static type without necessarily creating a readable runtime value. A readable binding is created only when a value is first assigned. In all type annotations, the type and name MUST be separated by one or more space characters, and other characters MUST not appear between them.
+A declaration MUST record the symbol's static type without necessarily creating a readable runtime value. A readable binding is created only when a value is first assigned. In all type annotations, the type and name MUST be separated by one or more space characters, and other characters MUST NOT appear between them.
 
 `int` and `float` type annotations MAY include a base specifier written immediately after the type name with no intervening whitespace, in the form `int{base}` or `float{base}`. The `{base}` suffix is part of the type annotation and therefore MUST appear before the required space that separates the type from the declared name. For example, `int{0d2} value` declares a binary integer, while `float{0x} value` declares a hexadecimal float. A base of `0` (typically written as the bare type name) denotes the parent type and accepts any valid numeric base.
 
@@ -63,7 +63,7 @@
 
 Assigning through a symbol whose current binding is a pointer MUST update the pointed-to target rather than replace the pointer object. Pointer cycles, including direct self-reference, MUST be rejected as runtime errors.
 
-When a built-in operator produces a transformed value from one or more operand arguments, any operand argument that is a pointer literal MUST be written back through the alias for that operand. Arguments that act only as flags, modes, delimiters, bounds, or other control inputs MUST not be written back unless they are themselves part of the transformed output.
+When a built-in operator produces a transformed value from one or more operand arguments, any operand argument that is a pointer literal MUST be written back through the alias for that operand. Arguments that act only as flags, modes, delimiters, bounds, or other control inputs MUST NOT be written back unless they are themselves part of the transformed output.
 
 Because `tensor` and `map` are atomic container types, ordinary assignment of those values MUST duplicate the container object by default. Shared mutable aliasing for containers therefore requires the explicit alias mechanism.
 

docs/specification/6-execution-model.html

@@ -49,7 +49,7 @@
 
 Observable effects MUST be represented explicitly in the execution record rather than being left implicit in host-language side effects. This includes printed output, consumed input, extension hook activity, runtime error creation, thread lifecycle events, and scheduler decisions that influence visible behavior.
 
-Logging configuration MAY change how much diagnostic data is retained, but it MUST not change the language semantics of the running program. In particular, enabling verbose tracing or disabling snapshots for privacy MUST affect diagnostics only, except that disabling the state logger necessarily removes replay artifacts that depend on that log.
+Logging configuration MAY change how much diagnostic data is retained, but it MUST NOT change the language semantics of the running program. In particular, enabling verbose tracing or disabling snapshots for privacy MUST affect diagnostics only, except that disabling the state logger necessarily removes replay artifacts that depend on that log.
 
 ---
 
@@ -61,15 +61,15 @@
 
 Each individual rewrite step MUST belong to exactly one active execution context. The implementation MAY choose statement-level or finer-grained interleaving, but whatever granularity it uses for a given execution MUST be reflected in the state log strongly enough to explain shared-state races, asynchronous errors, and cross-thread visibility of mutations.
 
-Runtime errors raised in background or parallel contexts MUST be attributed to the originating execution context in the log and reported according to the control-flow rules in [3.4](#3-statements.html#34-exception-handling), [3.5](#3-statements.html#35-loops), and [7](#7-tracebacks-and-error-handling.html#7-tracebacks-and-error-handling). A surrounding handler in another execution context MUST not intercept such an error synchronously unless some future language construct explicitly specifies that behavior.
+Runtime errors raised in background or parallel contexts MUST be attributed to the originating execution context in the log and reported according to the control-flow rules in [3.4](#3-statements.html#34-exception-handling), [3.5](#3-statements.html#35-loops), and [7](#7-tracebacks-and-error-handling.html#7-tracebacks-and-error-handling). A surrounding handler in another execution context MUST NOT intercept such an error synchronously unless some future language construct explicitly specifies that behavior.
 
 ---
 
 ### 6.5 Deterministic replay requirements
 
 When state logging is enabled, the interpreter MUST support deterministic replay from the seed configuration together with the recorded sequence of external inputs and nondeterministic choices. Replay MUST reconstruct the same transition sequence, the same observable effects, and the same terminal outcome as the original execution.
 
-Replay tooling SHOULD be able to resume from any serialized intermediate state whose required predecessor data is available. If an implementation redacts or omits diagnostic data, it MUST clearly indicate that omission and MUST not present the resulting replay record as complete when it is not.
+Replay tooling SHOULD be able to resume from any serialized intermediate state whose required predecessor data is available. If an implementation redacts or omits diagnostic data, it MUST clearly indicate that omission and MUST NOT present the resulting replay record as complete when it is not.
 
 The state log defined by this section is the normative source for tracebacks, diagnostics, and replay-oriented tooling. Any alternate implementation strategy remains conforming only if it preserves the same externally visible execution behavior and can expose an equivalent serialized transition history.
 

docs/specification/7-tracebacks-and-error-handling.html

@@ -25,7 +25,7 @@
 
 A traceback MUST be produced whenever a runtime error prevents normal forward execution, including but not limited to undefined identifier access, type mismatch, divide-by-zero, invalid control-flow transfer, or failed assertion.
 
-Errors raised inside background execution contexts MUST be recorded through the same error-reporting and state-logging mechanisms, but they MUST not synchronously transfer control to an exception handler running on a different thread. Nested handlers MUST continue to obey the language's innermost-handler rule.
+Errors raised inside background execution contexts MUST be recorded through the same error-reporting and state-logging mechanisms, but they MUST NOT synchronously transfer control to an exception handler running on a different thread. Nested handlers MUST continue to obey the language's innermost-handler rule.
 
 ---