Changelog

Dorpn is growing up. v0.4.1 introduces a self-updating compiler flag, while locking down syntax and semantics for better discipline and squashing long-standing bugs.

v0.4.1 — What's New

New compiler flag — --upgrade

Dorpn can now update itself. The new --upgrade flag fetches the latest release straight from the official GitHub repository and replaces the existing Dorpn install on your system.

dorpn --upgrade

Strict colon syntax

The colon : at the end of block headers — if, elif, else, func, loop, and keep — is now required. Previously the compiler would silently accept code without it, which led to inconsistency across codebases. Omitting the colon is now a syntax error, and the compiler points to the exact line and column where it was expected.

Enforced indentation rules

Dorpn now enforces a strict indentation policy. Only 2 or 4 spaces are accepted per indent level, and they must be used consistently throughout a block. Any other amount — 1 space, 3 spaces, tabs mixed with spaces — produces a clear error at the offending line. The old behavior of printing a warning and continuing silently has been removed entirely.

Multiple errors reported at once

Semantic analysis no longer stops at the first error it finds. All semantic errors in a file — type mismatches, undefined variables, invalid reassignments — are now collected and reported together in a single compiler run, instead of a fix-one-recompile-repeat cycle. Syntax-level errors from the lexer/parser still report one at a time for now, since a single syntax error can invalidate the rest of the file structure.

Colorful, categorized error output

Compiler errors are now color-coded by category — Semantic, Syntax, Lexor, and Indent errors each get a distinct colored heading.

Strict ask() prompt type

ask() now strictly requires its prompt argument to be a String, consistent with Dorpn's compiled, statically-typed design. Passing an Int, Bool, or any other type as the prompt now raises a clear Semantic Error instead of silently compiling into broken C output.

v0.4.1 — What's Fixed

Blank line on empty input in ask()

When using ask() to prompt for user input and the user pressed Enter on empty input, an empty line would appear in the terminal before the next prompt. This was cosmetic but noticeable, especially in loops that re-prompt until valid input is given. Fixed in both the C runtime and the JavaScript runtime backends — empty input no longer leaves a gap.

Deprecated types fully removed

String32 and Bool32 were marked deprecated in a previous release but continued to work silently, with no warning, no error. They have now been fully removed from the lexer, parser, and type system — using either name now correctly fails to compile.

Invalid type names no longer fail silently

Declaring a variable, function parameter, or return type with an unrecognized type name (a typo, or a removed type) used to be silently accepted as an untyped value, quietly bypassing all type-checking for that declaration. This is now caught immediately as a Syntax Error, pointing to the exact line and column.

Reassignment type checking was a no-op

Reassigning an existing variable to a value of an incompatible type (e.g. age = ask(...) where age was declared Int) was silently allowed — the compatibility check existed in code but its result was never used. Reassignment now correctly enforces the variable's declared type.

keep loops were never type-checked

A significant bug: any code inside a keep block was completely skipped by semantic analysis — no undefined-variable checks, no type mismatch checks, nothing. Errors inside loops went entirely undetected until they either crashed at the C level or silently produced wrong output. keep bodies are now fully analyzed like any other block.

Upgrading from v0.4.0

If you have existing .dpn files, a few things to check before building:

• Add a : to the end of every block header line if it's missing.
• Ensure all indentation uses either 2 or 4 spaces consistently.
• If you were relying on String32 or Bool32, switch to String / Bool — the 32-bit variants no longer exist.
• Double-check any ask(...) calls where the prompt isn't a plain string literal — it must now resolve to String.
• Code inside keep blocks that previously "worked" despite type mistakes may now correctly fail to compile — this is expected; it means bugs that were silently ignored before are now visible.