oberon07.com

Oberon-07 Frequently Asked Questions

21 September 2019

Summary

Questions and Answers

What is Oberon-07?

Oberon-07 is the current programming language designed by Professor Niklaus Emil Wirth. It is a revision of Oberon, influenced by Oberon-2 and a custom Oberon implementation from 1998 called Oberon-SA.

Why is Oberon-07 called Revised Oberon?

Revised Oberon originally referred to revisions made to the classic Oberon language (1988) as described in From Modula to Oberon, and the accompanying Report, in September 1989. The last reference to Revised Oberon was in the November 1990 revision, (the Reiser PIO has a minor revision to this version). In 2008, a new Oberon Report spoke of the new language Oberon-07, implemented in 2007, and subsequent revision of From Modula to Oberon again referred to Revised Oberon, as did some other papers.

Revised Oberon in Oberon-07 documents are a reference to the post-1988 Oberon language, re-revised in 2007. Perhaps Revised Oberon can now refer to the revisions made to Oberon-07 since 2011 for Project Oberon 2013, i.e. Oberon-11, but it appears that Wirth perceives Oberon-07 as another revision of the 1987/88 Oberon, a Revised Oberon since the first Revised Oberon of 1989, hence the date of 2007 in Oberon-07.

What is Modula?

Modula is a language begun in 1973 to investigate concurrency and multi-programming. It had a single report in March 1976. It was a simplification of Pascal with local modules, except that like Pascal, it was restricted to a single file for compilation. The first report of Modula-2 was in December of 1978, providing separate compilation and import/export of modules. The most obvious differences in this original report from later versions is that an implementation module specified the identifier of its definition, instead of being labeled as an IMPLEMENTATION, and the REAL type is not specified (an artifact of Modula-1). The next report was released in March 1980, followed by a second edition in December 1980. The report that followed was in 1982, as printed in the first and second editions of Programming in Modula-2, included the Medos implementation on Lilith. The Third Edition changed the module again so a definition module became an implicit export, relegating the EXPORT statement to local modules. The Fourth Edition made the INTEGER type more universal, making explicit its use with the MOD and DIV statements (commented on by Wirth in a Pascal newletter) and other built-in procedures, allowed the CARDINAL type to be a sub-range of INTEGER (due to 32-bit systems, such as the Ceres-1 running MEDOS V5 and Vamos, and the Macintosh with the ETH MacMETH compiler). Other changes to PIM3 found in PIM4 relate to string definitions and assignments, and opaque export for subrange types. There's also the curious addition of REM in the 1986 eidtion of Algorithms and Data Structures that didn't make it into PIM4. There were two German language editions, the second printed in 1992. Modula-2 was standardized by the ISO/IEC as 10514-1:1996.

Is there a standard for Oberon?

Sometimes called the Oberon Report, The Programming Language Oberon was first published in September 1987 (ETH Zürich) as a revision of the Modula-2 Report (PIM3). A follow up was published in July 1988, with corrections in January 1989.

Revised (Classic) Oberon was, or perhaps purposely was not, standardized through the "Oakwood Guidelines for Oberon-2 Compiler Developers", which defined a minimal standard library, and extensions for classic Oberon implementations. This required that the Oberon of the October Report, and the November 1990 From Modula to Oberon, with a revised Report, number 143, reports, begun in September 1989 (ETH Zürich Report 111), and finalized in the Reiser PIO of 1992, be preserved, and that Oberon-2 (started in 1991, and completed in 1995) be treated as an extension (as later Object and Active Oberon extensions did).

Unlike Modula-2, Oberon was never standardized by the ISO/IEC or ANSI (now INCITS), much to the relief of Wirth and his students. Oberon and Oberon-07 remain defined by Wirth's reports called The Programming Language Oberon.

See inf.ethz.ch/person/wirth/projects.html for a brief history of Wirth's work.

What texts are available for learning Oberon-07?

The text Programming in Oberon (PDF), along with the current (Revised) Oberon Report (PDF) written by Professor Wirth, provide a solid ground for learning Oberon-07. See the Oberon texts page for more.

A more basic introduction to programming doesn't yet exist for Oberon-07. An older Oberon-2 text, Into the Realm of Oberon by Eric Nikitin, provides an excellent bare-bones introduction to programming that works well with any of the freely available and downloadable Oberon system versions. Nikitin's book also works well with Oberon Microsystems' Blackbox Component Builder, other than having to change to Component Pascal's syntax for RECORDs in a couple exercises.

For a fuller coverage of computing science, see J. Stanley Warford's Computing Fundamentals, using Component Pascal and the Blackbox Component Builder. For understanding some of the details behind Algorithms and Data Structures, and some of the details of formal methods addressed in Computing Fundamentals, see Edsgar Wybe Dijsktra's Method of Programming.

If you have never worked with a computer before, or need a basic introduction to computers in general, Professor Brian Wilson Kernighan's Understanding the Digital World (a second edition of D is for Digital) is a good starting point.

What compilers are available?

See the Oberon-07 compilers page for more details.

Why does CASE not have an ELSE or OTHERWISE clause?

To quote Prof. Wirth, "...the ELSE clause should be reserved for exceptional cases, i.e. those that are neither numerous among the possible cases nor do occur frequently during program execution."

This makes sense where CASE is normally implemented with a jump table. A common objection to not having an ELSE clause is related to it being an error if the case label does not match. Oberon-07 does not require it to be an error: a non-match will continue processing the next statement after CASE, as if there were a blank ELSE. (Potentially, a specialized implementation might decide on having a non-match be an error or trap.)

ELSE has issues with maintainence and readability. It potentially obfuscates the thinking of the programmer. Is something passed to CASE that falls to ELSE that was unintended? What did the author intend to fall to ELSE? It is possible this will be overlooked in a future refactoring.

The Oberon philosophy is to focus on essentials and keep it as simple as possible, but no simpler. As Wirth once wrote, be "engaged crusaders against home-made complexity".

Is CASE going to be removed from Oberon-07?

The note in the 2013 edition of "Oberon at a glance", and the explanation in Project Oberon (2013), suggest that CASE is to be restricted to use as a type guard in RECORD subtypes. This is similar to its original purpose as a type guard in variant records as introduced in Pascal. (Variant records are not used in Oberon.) However, this change was not reflected in any of the 2013-2014 reports, and both the 2007 and new 2013 forms of CASE are found in the Project Oberon source. Though it may be that the Report reflects the 2007/2013 form for compatibility, the 22 February 2015 Report clarified that both forms are valid (which is consistent with the source for Project Oberon posted to Wirth's website).

Why are reserved words in upper-case?

This was originally from the language Mesa to distinguish built-in reserved words (such as procedure and module names, e.g. SYSTEM) from user-defined names. Perhaps this could also help avoid naming collisions with existing source texts from Algol, Pascal, and Modula(-1).

oberon07.com