Pascal.CodeCompared.To/Odin

Nothing is in scope implicitly — even printing requires import "core:fmt", where Pascal's writeln is a compiler built-in.

Pascal enforces a fixed order — const, type, var, procedures, main block — and a name must be declared before use. In Odin report could just as well be written after main.

Free Pascal compiles one .pas file at a time and finds its units through -Fu search paths; Odin needs no search paths and no unit list at all.

Commenting out a region of Pascal that already contains a { … } comment terminates the outer comment early at the inner } — a classic source of confusing errors. In Odin the compiler counts opening and closing pairs, so wrapping any region always does what you meant.

Pascal has two unrelated mechanisms: the writeln width specifiers built into the compiler (ratio:6:2) and Format from SysUtils taking an array of const. Odin folds both into one.

Every variable is zero-initialized, so an uninitialized int is reliably 0 rather than whatever was on the stack.

The same two characters mean something subtly different in each language: Pascal uses := purely for assignment to an already-declared variable, while in Odin it always introduces a new name.

Odin constants are untyped until used, so MAX_SIZE can be assigned to an i8 or an i64 without a cast as long as the value fits — the compiler range-checks at each use site.

That removes the guesswork behind Pascal names like Integer, whose size depends on the mode and target. int is the closest analog to Pascal's Integer, and size_of tells you what it is on this target.

The upside is that a mixed-width arithmetic expression can never quietly truncate or change signedness, which is the source of a whole class of bugs in both Pascal and C.

Pascal's type Celsius = Double creates an alias, not a new type — assigning a Celsius to a Fahrenheit compiles happily, because both are Double as far as the compiler is concerned. distinct is how you make unit-mismatch bugs a compile error rather than a code-review responsibility.

For text that may contain non-ASCII, iterate with for character in greeting, which decodes runes — the row below covers that.

Free Pascal strings are reference-counted mutable buffers that copy on write, so poking a character in place is legal there. Odin makes you construct a new string, and makes the allocation visible.

This is deliberate: concatenation allocates, and the language refuses to hide an allocation behind an operator. Free Pascal's reference counting handles the cleanup for you, at the cost of you not knowing where the allocations happen.

That view semantics is a meaningful difference from Copy, which builds a new reference-counted string. Note the sentinel too: Pascal's Pos returns 0 for "not found", which Odin cannot use because 0 is a valid index.

The Pascal loop opposite reallocates the whole string on every iteration, which is quadratic in the number of appends — a habit worth unlearning. The builder makes it linear.

So the offsets advance by more than one for multi-byte characters, unlike the dense 1-to-Length range a Pascal loop walks. Index the string directly (word[0]) when you genuinely want raw bytes.

In exchange, the length is part of the type, arrays compare with ==, and printing one with fmt.println shows every element rather than requiring a loop.

Watch that loop-variable order: for value, index in primes puts the element first and the index second — the reverse of what most languages do, and the single easiest thing to get backwards when starting out.

Pascal has no equivalent — you write the loop, as the anchor column does. The swizzles reflect Odin's origins in graphics and game programming.

This is the single biggest ergonomic gain over Pascal here. The Pascal equivalent is either an open array parameter or passing the bounds alongside by hand.

Free Pascal's array of T is reference counted and freed automatically. In return for the manual delete you get append instead of SetLength reallocating on every growth, and the ability to slice with numbers[:] and hand it to any []int procedure.

Pascal has no associative array in the language — you reach for TFPGMap from the fgl unit, with generic-specialization syntax and manual Create/Free. The found flag is worth internalizing: a plain read of a missing key returns the zero value silently.

The practical benefit is that a row is itself a value of type [3]int — it can be printed, compared, assigned, or passed to a procedure on its own, which the Pascal form does not allow.

Namespacing means two enums may both have an Apple without colliding, a real limitation of Pascal's flat enumeration scope. Best of all, %v prints the member's name, where Pascal's writeln can only give you the ordinal via Ord.

This is the clearest piece of Pascal DNA in Odin. Sets are a Wirth idea that almost no modern language kept, and Odin kept it — card even returns the population count, matching Free Pascal's function of the same name.

The operations are identical to Pascal's; only the spelling changed, since Pascal overloads the arithmetic operators (+, *, -) instead. Odin's choice makes the underlying bitfield representation visible.

So %v can print Apple instead of 0. The array is guaranteed to have exactly one slot per member, which means adding a new Fruit cannot leave a gap in the table.

Requiring braces quietly removes Pascal's dangling-else ambiguity and the "forgot the begin…end" bug. The initializer form has no Pascal equivalent at all.

The semantics match Pascal closely — you must write fallthrough explicitly to get C's behavior, which Pascal never had either.

This is the safety property Pascal's case lacks: adding a fifth Direction to a Pascal program leaves every existing case silently incomplete, while in Odin the compiler points at each one. #partial says so in the source rather than leaving the reader to guess.

Counting down uses the C-style three-clause form. The four shapes are a range, a three-clause loop, a bare condition, and iteration over a collection.

Odin also has no Inc/Dec procedures and no ++ operator — countdown += 1 is the idiom.

Escaping a nested loop in Pascal means declaring a label and using goto. Here the jump target is always a loop boundary rather than an arbitrary point in the procedure, which keeps the control flow readable.

Free Pascal's {$IFDEF} is a directive operating on text before the compiler sees it, so a typo is a branch that silently never fires. In Odin it is a compile error.

There is no assigning to the function's own name or to Result, so there is no way to fall off the end of a function having forgotten to set it.

So the call site itself tells you the variable may change, which Pascal's Double(count) does not. Parameters are otherwise immutable inside the procedure, which is closer to Pascal's const mode than to its plain by-value mode.

Returning several values is the single change that most reduces Pascal's reliance on var out-parameters. Odin will not let you silently ignore a result by accident.

Positional-only Pascal cannot express that. Named arguments may appear in any order, and they make a call with several boolean flags readable without a comment.

Pascal's open array parameter is close in spirit, but the caller must write the values as an array constructor.

They are not closures — a literal cannot capture surrounding local variables, which keeps a procedure value a bare code pointer with no hidden allocation behind it.

Those are the ergonomic gains over Pascal records: the reader does not have to remember declaration order, and there is no per-field writeln. Both languages give you value semantics — assigning a struct copies it.

The compiler's own words are "disallowed as it is considered bad practice … outside of immediate refactoring" — for exactly the hazard every Pascal programmer knows, where after with an unqualified name may silently mean a field instead of the local you were looking at. What survives, and is still encouraged, is using on a struct field — the next row.

This gives Odin composition without inheritance — the embedded value is still a plain field you can pass to any procedure expecting a Named. Pascal has no equivalent for records; you would reach for a class and inherit.

Note that rectangle.width works on a ^Rectangle without an explicit ^: Odin auto-dereferences pointers on field access, as Free Pascal does for class instances. The Pascal column needs {$modeswitch advancedrecords} to put a method on a record at all.

Both let you strip padding for a struct that must match an on-disk or on-the-wire layout. The introspection matters when you are matching a C header rather than guessing.

Both languages spell the null pointer nil. Odin also has no pointer arithmetic in ordinary code: to walk memory you use a slice, which carries its length and is bounds-checked in debug builds.

A forward type declaration is unnecessary too — Node may refer to ^Node before the declaration completes, so Pascal's PNode = ^TNode dance is not needed.

So an allocation with no matching release is visible at a glance, rather than sitting several screens below it. Note that a defer the compiler can prove is unreachable — after os.exit, for instance — is a compile error rather than a silent no-op.

This is the feature with no Pascal counterpart at all, and the one most worth understanding. Free Pascal's memory manager is global: you install a different TMemoryManager process-wide or thread your own allocator through every routine by hand. The arena here is a fixed byte buffer, so nothing needs freeing individually.

That removes most of the bookkeeping that makes manual memory tedious. It is the closest thing Odin has to Free Pascal's automatic string management, except you decide exactly when the reclamation happens.

Pascal's variant record shares storage between alternatives but does not enforce which one is live — the case tag is documentation the compiler does not check, so reading the wrong variant reinterprets unrelated bytes. A union also has a nil state meaning "no variant set yet", which a variant record cannot represent.

Pascal's equivalent switches on a tag you maintain by hand and then reads fields the compiler never associated with that tag. A mistake there is silent; here it is impossible.

This matters because a sentinel like -1 is only safe while -1 is not a legitimate result — with Maybe, the whole range of int stays available.

So the failure is visible in the signature rather than discovered at runtime. The trade-off is real: Pascal can let an error propagate up several frames untouched, while in Odin each frame must pass it along — which the or_return operator below exists to make painless.

The shape is one an experienced Pascal programmer already writes by hand — an error enum returned as a status code — but with the value returned alongside it, and an unset error meaning "no error".

This is the piece that makes return-code error handling bearable: the five-line manual check in the Pascal column collapses to a suffix. Because the enclosing procedure's results are named, the compiler knows what to return.

Where or_return propagates a failure, or_else swallows it and substitutes a default. The Pascal version needs a mutable variable and an if to say the same thing.

One difference to watch: because os.exit never returns, the compiler rejects any defer that could only run after it — an unreachable cleanup is an error here rather than something you discover in a leak report.

A Pascal unit is one file split into an interface section and an implementation section. In Odin the declaration you want is never behind a header, and capitalization carries no meaning.

Pascal's uses dumps every name into the current scope, so two units exporting the same identifier collide and the later one silently wins.

Each distinct type instantiates a separate copy at compile time, exactly as Free Pascal's generics do, but the type argument is deduced rather than written out. Note the Pascal column must assign to Result: inside a generic, the routine name denotes the generic itself.

Compare the Pascal column's specialize TFPGList<Integer> plus Create/Free: Odin's version is a plain value with no class machinery. The procedures are named stack_push/stack_pop because pop is already a builtin.

Odin's parametric polymorphism binds values as well as types, so doubled gives back an array of exactly the length it received. Pascal generics parameterize over types only, so the closest equivalent loses the compile-time length.

Reorganizing an array of records into parallel arrays — so that a loop touching one field reads contiguous memory instead of striding past the others — is a standard optimization. In Pascal it means a new type and rewriting every access site. This is Odin's signature feature for game and simulation work, and it has no equivalent in Pascal, C, or Go.

That is useful in an audio callback, an interrupt handler, or a frame budget, where the guarantee you want is not "allocates rarely" but "cannot allocate". The Pascal loop opposite allocates on every iteration and gives you no way to say "not here".

Unlike Free Pascal's -gh switch this is scoped — you can track one subsystem and leave the rest alone — and it needs no special build, so it works the same in a release binary.