Oberon turns a 30 year old systems language into a multi backend compiler

A parser that became a compiler, and a language called Oberon+

The README explains the project through its own growth, and the history is the point.

It started out as an Oberon-07 parser, code model and transpiler written in C++ and Qt, with the goal of building tools to understand the Lola-2 compiler and to automatically translate it into maintainable C++ with minimal dependencies on other C++ libraries, and with no dependencies on the Oberon System. The related repositories are Lola and LolaCreator.

The stated reason Oberon suited this work is that it is decently simple but still powerful enough to build real-world software, since it supports pointers, static and stack based data structures and call by reference, which are not usually available in scripting languages. Another goal was to study the feasibility of reusing first LuaJIT and then Mono as a backend for statically typed languages, and the current compiler can map full Oberon+ to CIL/ECMA-335 bytecode and to C99 source code.

Oberon+ itself emerged from the author asking what properties the language would need so it could be used for his own systems without giving up simplicity. It is a general-purpose, procedural and object-oriented language in the tradition of Oberon-07, Oberon-2 and Oberon 90, keeping all the elements of those languages and adding generic modules, enumerations, and simplifications such as lower case keywords, optional semicolons and flexible declaration sequences. The language report and the dedicated language site carry the specification.

What the repository actually contains

The README lists the contents, and the naming convention is the fastest way to understand the layout. Files prefixed Ob are the old Oberon-07 side, and files prefixed Obx are the new Oberon+ side.

The Oberon-07 side is the old validating parser with code model, a Lua source code transpiler, a C++ transpiler and a LuaJIT bytecode compiler. Alongside it sit the old OberonViewer, the Oberon-07 IDE and OBNLC, the command line version of the compiler and transpiler.

The Oberon+ side has a validating parser, a code model and compilers for LuaJIT, for CIL/ECMA-335 bytecode and for C99. The new Oberon+ IDE comes in a separate build for LuaJIT and for Mono, with OBXLJ for LuaJIT and OBXMC for Mono as the command line compilers. There is also the Oberon+ LL(1) EBNF grammar, the Are we fast yet and Hennessy benchmark suites ported to Oberon+, and SDL2 and NAppGUI external library modules with examples.

There is no installer to run and the README gives no build commands, so a new user works from the sources: the root directory is a wall of C++ and Qt files, with ObAst.cpp and ObAst.h for the tree, ObCodeModel.cpp and ObCodeModel.h for the model, ObParser.cpp, ObLexer.cpp and ObSynTree.cpp for the front end, and separate generators such as ObLuaGen.cpp, ObObxGen.cpp, ObLjbcGen.cpp and ObCppGen.cpp for the backends. The .pro files are the Qt project files, one per tool.

The planned features list is mostly checked. The validating parser, the IDE with semantic navigation and a source-level debugger, the LuaJIT backend, the CIL/ECMA-335 backend for both IL and a direct assembly generator, the minimal Mono runtime as an alternative to the LuaJIT VM, the Foreign Function Interface, the C transpiler backend in place of the originally planned LLVM backend, and the cross-platform OS abstraction and GUI library are all marked done. One item remains open: writing documentation and focus articles, marked as work in progress.

The IDE is where the language work becomes usable

The Oberon+ IDE section describes a lean IDE, separate for LuaJIT and Mono, and the feature list is where the language design shows through.

There is full support of the new language, syntax highlighting, and semantic code navigation with a jump to the declaration of an identifier on CTRL+click. The IDE can mark all identifiers referring to the same declaration, and there is a cross-reference view listing all instances of an identifier, a module view showing the records declared in a module together with their bound procedures, and a hierarchy view showing the inheritance relation of a selected record or the overrides of a selected bound procedure.

The project model is that project files combine modules into a single project and associate them with virtual import paths, which is what a compiler for a modular language needs.

Two things stand out for a tool of this kind. There is a built-in LuaJIT or Mono engine, so the IDE runs the code it edits. And there is a bytecode view, in LuaJIT or IL assembler syntax, synchronized to the source, which is a considerable aid when the question is what the compiler actually emitted.

The debugger is integrated and source level, with breakpoints, a stack trace and a locals view, and there is a built-in optional Oakwood or Oberon System backend library.

One deprecation is stated plainly: the LuaJIT version of the IDE, ObxIde.pro, is deprecated, and the Mono version ObxIde2.pro should be used instead. That is a small detail with a large practical consequence for anyone starting out, since the file names are easy to confuse.

Three backends, and what each one cannot do

The two backend sections are short, and the constraints are stated just as clearly as the capabilities.

For the CIL and ECMA-335 route, the compiler generates either IL assembly language or assembly binaries compatible with ECMA-335 and ISO 23271:2012, and the generated code runs on Mono, .NET and CoreCLR. It can optionally generate Mono debug symbol files. The full Oberon+ language including generics and the Oakwood libraries are supported, while the SYSTEM module is not supported, and not necessary. There is also an FFI with dedicated Oberon+ language constructs for C library integration, alongside a separate tool that converts C headers into Oberon+ definition modules.

For the C99 transpiler, the compiler generates C code compatible with ISO 9899:1999 with no other dependencies. That is a striking claim for a transpiler from a language with pointers and call by reference, and it is the point of the exercise: the generated C has to be plain and portable, with no runtime of its own.

The repository carries the benchmarks that back the performance claims. There are Linux and Windows results for the Are we fast yet suite, a C++ and Lua benchmark with hundreds of tests, which the README links as a Linux report and a Windows report in the testcases/Are-we-fast-yet directory. The examples directory holds the same suite migrated to Oberon+, plus Collections.obx demonstrating generic programming with collections and iterators, Fibonacci.obx, Lists.obx, Unicode.obx, a traditional syntax folder and a Wikipedia example in Oberon+.

The larger compatibility example named in the README is the Oberon System 3, in a separate repository, which is described as demonstrating backward compatibility.

The work is done, the documentation is not

Two things about the state of the project are worth stating plainly, because they shape what you can expect.

The first is that the documentation is the open item. The planned features list has one unchecked box, and it is the one that matters most for adoption: write documentation and focus articles, marked as work in progress. The README itself is a project history and a feature inventory rather than a tutorial, and the deeper explanation lives in the linked articles about implementing call by reference and call by name in Lua and about whether the Mono CLR is slower than CoreCLR.

The second is the release history. The listed releases are EH_MVP, the exception handling and some other new language features, from May 2022; NAPPGUI_MVP, the cross-platform OS abstraction and GUI library milestone, from January 2022; and FFI_MVP, the Oberon+ cross-platform FFI language milestone, from December 2021. These are milestone tags for a long project, not a stream of point releases, and the last push to master was on 2026-08-24.

The licence situation is also mixed at the file level. The repository contains both LICENSE.GPL2 and LICENSE.GPL3 at the root, and the project is GPL-2.0, so the terms for the code and for the external library modules, which include SDL2 and NAppGUI, are worth checking separately before you redistribute anything built on it.

Editorial conclusion

Adopt Oberon if you are interested in systems language implementation, in porting a statically typed language with pointers and call by reference onto a modern runtime, or in the Oberon+ language itself, since the repository gives you the parser, a code model, three backends and an IDE in one place. Do not adopt it for day to day production work on a maintained language, because the language specification is still being written and the listed release tags are development milestones from 2021 and 2022. Before you start, read the language report and the dedicated language site, and check the git history for the areas you plan to touch, and note the maintenance picture, with the last push on 2026-08-24.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-2.0
3. README
4. Releases
5. rochus-keller/Oberon on GitHub