[Oberon] Micron is a modern Oberon with the power of C

[Rochus Keller]

@ Jörg

Fair point and I spent a lot of time with the trade-offs. Since Micron lets you take the address of any variable, VAR would duplicate a mechanism the language already has, so following Wirth's rule of keeping a language as simple as possible, Micron keeps only the pointer. In return, "Sorter.Sort(@a,.." shows at the call site that a may change, which you don't see with a VAR param.

Oberon made the opposite choice: it kept VAR and confined address-taking to SYSTEM. But SYSTEM.ADR yields a plain LONGINT, and SYSTEM.GET, SYSTEM.PUT and SYSTEM.VAL read, write and reinterpret memory through such integers. From that point on the compiler no longer knows what the address refers to: the element size, bounds and type have to be maintained by hand, and the garbage collector does not see an object whose only reference is stored in an LONGINT. The systems code that needs this is therefore largely written without type checking, and also assuming a pointer has 32 bits. In Micron, @v yields a typed pointer ^T, pointer arithmetic (ptroff, inc) steps in units of T, and a reinterpretation is an explicit cast at the place where it happens, so even the low-level code stays under the type checker.

Best regards
R.K.
_______________________________
From: Jörg
Sent on: Sun, 08 Nov 2026 17:23:02 +0100
To: ETH Oberon and related systems
Cc: 
Subject: Re: [Oberon] Micron is a modern Oberon with the power of C

PROCEDURE Sort*(a: ^[]INTEGER
Sorter.Sort(@a,


That is rather C than Oberon :-)
Personally, I find it cleaner to hide pointers and adresses as much as possible unless you do low level stuff.


PROCEDURE Sort*(VAR a: ARRAY OF INTEGER
Sorter. Sort(a, 


br
Jörg