Oberon-1

From Wikipedia, the free encyclopedia

Oberon
Paradigm imperative, structured, modular
Appeared in 1986
Designed by Niklaus Wirth
Typing discipline strong, static
Influenced by Modula-2
Influenced Oberon-2, Zonnon

Oberon is a programming language created in 1986 by Professor Niklaus Wirth (creator of the Pascal, Modula, and Modula-2 programming languages) and his associates at ETH Zurich in Switzerland. It was developed as part of the implementation of the Oberon operating system. The original intention was to use Modula-2 as the implementation language but it lacked the required safe type-extension facilities. Also, it was planned to eventually publish the full details of the operating system and compiler so that they could be studied and understood. These factors led to the decision to design a new language which concentrated on just the essential features necessary for the task in hand. The name is from the moon of Uranus, Oberon.

Oberon is very much like Modula-2 in its syntax, but is considerably smaller. Oberon's feature simplicity leads to considerable space and coding efficiency for its compilers. The full language can be specified in a page of EBNF. The Oberon report is, at 16 pages, about ⅓ the size of the Modula-2 report, and one of the early full compilers was only about 4000 lines long. Unlike Modula-2, it has garbage collection.

Oberon was designed for Oberon operating system which ran on the Ceres workstation (built around the National Semiconductor 32032 CPU) and the Chameleon workstation. The Oberon language (and later, Oberon-2) has now been ported to many other operating systems, including the Java platform, where Oberon source code compiles to source code in Java, or to bytecode for a Java virtual machine. The Oberon operating system is also available for several hardware platforms other than the original workstation.

Contents

[edit] Design goals

Oberon is designed to be a 'safe' language; it employs array bounds checking, garbage collection and strong type checking. These features, particularly ones which enable logic errors to be detected as early as possible (i.e. at compile-time), can significantly reduce the number of bugs occurring in a program at runtime. However, some features included in other languages in an attempt to reduce bugs (e.g. enumerations and programmer-defined ranges on integers), were omitted. Consequently, more care should be taken by the programmer, when working with numeric expressions, to avoid logic errors.

Oberon was intended to make mistakes harder in part by making code less opaque, and in part because features not included cannot be misused. This approach can be taken even further, as in APL, which is both exceptionally terse and renowned for being less than easy to understand, but Oberon was deliberately constructed to not oversimplify.

As this is an intent whose success cannot be easily quantified, there remains some disagreement that Oberon has achieved its intended goals in this respect. One objection to its strategy of language design simplification was expressed by Jean Ichbiah, the architect of Ada when Wirth criticized Ada for being too big; he responded "There are times when Wirth believes in small solutions for big problems. I don't believe in that sort of miracle. Big problems need big solutions!" Oberon developers have even felt that Oberon went too far in this respect -- Oberon-2 returned the 'FOR' statement to that version of the language.

It can be argued that failure to include a feature may force the programmer to reimplement the feature in his code, leading to multiple 'wheel reinvention' and consequent problems. Libraries can mitigate this -- more or less -- effectively depending on the feature and a language's graceful use of such libraries. Java is an example of a relatively simple language (though far less so than Oberon) embedded in large standard libraries. (Oberon has a much smaller standard library than Java.) As much of the effort of learning any language is learning the standard libraries, Ichbiah's objection above can be extended to a strategy of simplification by moving features from the core language into standard libraries. Wirth, and Oberon fans, argue that Oberon has essentially, and effectively, avoided this problem.

[edit] Interesting features

[edit] Key characteristics

The following features characterise the Oberon language:

  • Pascal-like, but more consistent, syntax
  • Type-extension with strong type-checking
  • Modules with type-checked interfaces and separate compilation
  • Compatibility between all numeric types (mixed expressions)
  • String operations
  • Support for system programming

[edit] Visibility flags

Global variables, types, constants, and procedures are by default only visible within the declaring module. They may be made public to other modules by suffixing them with a visibility flag, namely an asterisk (*) for read-write permission. The default was chosen to ensure safety in case a flag was inadvertently omitted.

Local variables, types, constants, and procedures are always visible only to the declaring procedure.

[edit] Call by reference or by value

Two possible modes are available for procedure parameters. Call-by-value (CBV) allows expressions to be used as parameters, so that the value of the expression is passed down to the procedure. Call-by-reference (CBR) allows variables to be used, so that the value of the variable may be changed by the procedure. A procedure may declare a CBR parameter by prefixing it with the VAR keyword.

[edit] Available implementations & further language variants

[edit] Oberon

No-cost implementations of Oberon (the language) and Oberon (the operating system) can be found on the Internet (several are from ETHZ itself).

[edit] Oberon-2

A few changes were made to the first released specification (object-oriented programming features were added, the 'FOR' loop was reinstated, for instance); the result was Oberon-2, currently the most common implementation. There is a release called Native Oberon which includes an operating system, and can directly boot on PC class hardware. A .NET implementation of Oberon with the addition of some minor .NET-related extensions has also been developed at ETHZ.

Oberon-2 compilers maintained by ETH include versions for Windows, Linux, Solaris, Mac OS X.

There is an Oberon-2 Lex scanner and Yacc parser by Stephen J Bevan of Manchester University, UK, based on the one in the Mössenböck and Wirth reference. It is at version 1.4.

[edit] Related languages

Development has continued on languages in this family. A further extension of Oberon-2 produced Component Pascal, currently supported by Oberon Microsystems, a commercial company spun off from ETHZ, and by Queensland University of Technology. In addition, the Lagoona and Obliq languages carry the Oberon spirit into specialized areas.

ETHZ has released Active Oberon which supports active objects, and the Bluebottle operating system and environment (JDK, HTTP, FTP, etc) for the language. As with many prior designs from ETHZ, versions of both are available for download on the Internet. As this is written, both single and dual x86 CPUs and the StrongARM family are supported.

Recent .NET development efforts at ETHZ have been focused on a new language called Zonnon. This is an extended Oberon language that also supports the concept of active objects. Additional new features include operator overloading and exception handling. Zonnon is available as a plug-in language for the Microsoft Visual Studio for .NET development environment.

Oberon-V (originally called Seneca, after Seneca the Younger) is a descendant of Oberon designed for numerical applications on supercomputers, especially vector or pipelined architectures. It includes array constructors and an ALL statement. (See "Seneca - A Language for Numerical Applications on Vectorcomputers", Proc CONPAR 90 - VAPP IV Conf. R. Griesemer, Diss Nr. 10277, ETH Zurich.)

[edit] See also

[edit] External links

[edit] General

[edit] Evolution of Oberon and Oberon-2