Clarify language description and wording in docs and improve API section phrasing

README.md

@@ -6,12 +6,12 @@
 
 ## What is it?
 
-YesNt is an interpreted scripting language inspired by assembly. The core idea is simple: each line maps to one primary statement. Lines are processed top-to-bottom, and inline tokens (like `${variable}` or `%read_line`) are substituted before the statement executes. Postfix modifiers like `calc` and `task` can also appear at the end of a line to evaluate arithmetic or fork execution into a background thread.
+YesNt is a line-based, interpreted scripting language. The core idea is simple: each line maps to one primary statement. Lines are processed top-to-bottom, and inline tokens (like `${variable}` or `%read_line`) are substituted before the statement executes. Postfix modifiers like `calc` and `task` can also appear at the end of a line to evaluate arithmetic or fork execution into a background thread.
 
 **Key characteristics:**
 
 - **Line-based execution:** Lines are processed top-to-bottom. Each line is a self-contained statement
-- **Assembly-inspired control flow:** Labels, `goto`, and conditional jumps alongside structured `if`/`while` blocks
+- **Explicit control flow:** Labels, `goto`, and conditional jumps alongside structured `if`/`while` blocks
 - **Explicit scoping:** `var` for function-local variables, `global` for cross-scope shared state
 - **Functions with stacks:** Arguments and return values are passed via explicit push/pop stacks (`push_in`, `%in`, `push_out`, `%out`)
 - **Background tasks:** Any line can be forked into a background execution flow with `task`

docs/README.md

@@ -1,6 +1,6 @@
 # YesNt Documentation
 
-YesNt is a line-based, interpreted scripting language inspired by assembly.
+YesNt is a line-based, interpreted scripting language.
 Each line is one statement. There are no multi-line expressions.
 
 ## Guides

docs/library-api.md

@@ -170,10 +170,10 @@ Use `StatementAttribute.Priority` to control ordering relative to built-in state
 
 ## Removing and disabling built-in statements
 
-Use these methods to restrict which built-in keywords are available — useful for sandboxing
+Use these methods to restrict which built-in keywords are available, useful for sandboxing
 or replacing a built-in with a custom implementation.
 
-### `RemoveStatement` — permanent removal
+### `RemoveStatement` - permanent removal
 
 Removes all handlers for the given keyword. Any script line that would have matched the
 keyword now triggers an **"Invalid statement"** error.
@@ -188,7 +188,7 @@ interpreter.Execute(new List<string> { "exec notepad" });
 // Terminates with: Invalid statement
 ```
 
-### `DisableStatement` — silent no-op
+### `DisableStatement` - silent no-op
 
 Disables all handlers for the keyword. The keyword still **matches** (so no error is raised),
 but has no effect. Use `EnableStatement` to restore the original behaviour.
@@ -207,7 +207,7 @@ interpreter.Execute(new List<string>
 });
 ```
 
-### `EnableStatement` — restore a disabled statement
+### `EnableStatement` - restore a disabled statement
 
 Restores the original handlers saved when `DisableStatement` was called.
 Has no effect if the statement is not currently disabled.
@@ -221,7 +221,7 @@ interpreter.EnableStatement("sleep");   // sleep works normally again
 ### Replacing a built-in statement
 
 Call `RemoveStatement` to remove the built-in handlers, then `AddStatement` to install your own.
-Simply calling `AddStatement` with the same keyword name will **not** replace the built-in —
+Simply calling `AddStatement` with the same keyword name will **not** replace the built-in statement,
 it will add a second handler that fires alongside the original.
 
 ```csharp