H. Mossenbock and N. Wirth. The programming language Oberon-2. Structured Programming, 12(4):179--195, 1991.  Home/Search   Document Not in Database   Summary   Related Articles   Check

....[12] platforms, and the Oberon operating system [11] projects were developed in parallel with the language, and allowed to test and evaluate the language improvements. Many experimental language extensions have been proposed for Oberon at, and outside of the ETH. Object Oberon [19] Oberon 2 [20], and Froderon [7] explored adding further object oriented features to the language; Oberon V [9] proposed additions for parallel operations on vector computers; Oberon XSC [15] added mathematical features to support scientific computation; Module Embedding [24] was also proposed. Concurrency was ....

....inherited from the base type of the record, but it must have the same signature. Note: We decided to declare the methods in a object scope, because they belong to the record scope and can only be accessed through record instances. This simplifies the method declaration (no receiver, as in Oberon2 [20]) and the access to the fields and methods following the well known 4 Oberon scoping rules. We were aware that cyclic references would be a problem (i.e. whenever two object types mutually refer to each other) but considered the conceptual elegance of the language more important. The solution to ....

H. Mossenbock and N. Wirth. The programming language Oberon-2. Structured Programming, 12(4):179--195, 1991.

....loading and linking at runtime, has to be created as well. We currently have two independent implementations of Lagoona. The first prototype is an interpreter for Lagoona and is written in Python. The accepted language [16] resembles closely the original Lagoona syntax [12] based on Oberon 2 [33]. The goal of this interpreter is to explore future language features and various language dialects e#ectively. To this end, it supports multiple frontends. The frontend for the language with Oberonbased concrete syntax is complete, and a frontend for the Java based concrete syntax used throughout ....

Hanspeter Mossenbock and Niklaus Wirth. The programming language Oberon-2. Structured Programming, 12(4):179--195, 1991.

....is able to establish that correctness. Gardens Point Component Pascal (gpcp) is a compiler for the whole of the language Component Pascal. All of issues listed above needed to be resolved, in order to achieve this outcome. 1. 2 Why Component Pascal Component Pascal[7, 6] is a dialect of Oberon 2[9, 5]. The language was designed by Clemens Szyperski and others for Oberon Microsystems BlackBox Component Builder framework. Like Oberon 2 it is a small, object oriented language supporting single inheritance based on extensible records. Compared to Oberon 2, Component Pascal has a number of new ....

H. Mossenbock and N. Wirth. The programming language oberon-2. Structured Programming, 12:179--195, 1900.

....restrictions are accepted by our user community that wants to take advantage of the benefits of an object oriented programming style but can comfortly live without storage allocation in a real time controller. Our paper presents a solution to this problem that handles programs written in Oberon 2 [24], a Pascal like language with extensions for object orientation. The solution presented addresses the problems that are faced by users of similar languages, e.g. Java. 3 System Overview The tool for the WCET approximation is implemented as part of the XOberon preemptive real time operating ....

H. Mossenbock and N. Wirth. The programming language Oberon-2. Structured Programming, 12(4), 1991.

....hiding in the way our units do was Mesa [38] with its definition modules and implementation modules. The Mesa designers appear to have been influenced by Parnas s classic paper on decomposing systems into modules [46] Mesa in turn influenced Modula [50] Modula 2 [51] Modula 3 [44] Oberon 2 [40], and Ada [4] Ernst, Hookway, and Ogden have studied the problem of specifying Modula 2 programs where the objects of a module may share some global state [12] These authors share our concern for modular verification, but the possible scopes they consider are not rich enough to allow subclasses ....

H. Mossenbock and N. Wirth. The programming language Oberon-2. Structured Programming, 12(4):179--195, 1991.

....to plain actions, we give our extension a firm foundation in the Refinement Calculus. Keywords: action systems, Action Oberon, objects, concurrency, synchronization, type bound actions TUCS Research Group Programming Methodology Research Group 1 Introduction Action Oberon extends Oberon 2 [21] with actions for modeling parallel and distributed computations. The extension is based on the theory of action systems [5] and was proposed by Back and Sere [7] and implemented by Hedman [13] An action system is a parallel or distributed program where parallel activity is described in terms of ....

....and the deallocation of objects, section 5 discusses inheritance of type bound actions, section 6 provides a foundation for type bound action in the Refinement Calculus, and section 7 draws a conclusion and gives an overview of related and further work. 2 Action Oberon base language Oberon 2 [21] is the successor of Pascal and Modula 2. Modula 2 adds modularization to Pascal. Oberon 2 extends Modula 2 with object oriented concepts in form of type extension on record types (subtyping inheritance) as well as typebound procedures (methods) Oberon 2 has been chosen as a base language because ....

P. Mossenbock and N. Wirth. The programming language Oberon-2. Structured Programming 12:179--195, 1991.

....towards classes. Today s object oriented programming languages (OOPL) provide only a subset of these abstraction mechanisms. Pure OOPLs provide the class construct (Smalltalk, GR83] or the object construct (Self, US87] Others provide classes, or their equivalent, and modules (Oberon 2, MW91] Eiffel, Mey92] and (C , ES90] While data structures and procedures are smaller grained abstractions, the principal means of abstraction and encapsulation in the above mentioned languages is the class object construct, constituting a unit of state and behavior. The next larger grained ....

....and procedures are smaller grained abstractions, the principal means of abstraction and encapsulation in the above mentioned languages is the class object construct, constituting a unit of state and behavior. The next larger grained abstraction entity within a program is the module. In Oberon 2[MW91] a module consists of a collection of constant, type, variable and procedure declarations, along with statements that serve to initialize the variables. Modules provide for syntactic structure in large systems and are often used as a unit for separate compilation and dynamic loading. As ....

H. Mossenbock and Niklaus Wirth. The programming language Oberon-2. Structured Programming, 12:179--195, 1991.

.... alternating phases of autonomous computation and motionless mutual observation (lock step) PROMOTER will be specified as a generic extension scheme for statically typed object oriented imperative languages, e.g. C (the first author s preference for pragmatic reasons) Eiffel [4] or Oberon 2 [5, 6] (both the second author s preference) The actually chosen language is called the host language in this article. Not surprisingly, mainly the type system and the expressions of the host language will be extended. In the rest of the article, we will discuss the programming model concepts and ....

H. Mossenbock and N. Wirth. The programming language Oberon-2. Structured Programming, 12, 1991.

.... alternating phases of autonomous computation and motionless mutual observation (lock step) PROMOTER will be specified as a generic extension scheme for statically typed object oriented imperative languages, e.g. C (the first author s preference for pragmatic reasons) Eiffel [4] or Oberon 2 [5, 6] (both the second author s preference) The actually chosen language is called the host language in this article. Not surprisingly, mainly the type system and the expressions of the host language will be extended. In the rest of the article, we will discuss the programming model concepts and ....

H. Mossenbock. The programming language Oberon-2. Technical report #160, ETH, Zurich, 1991.

....has many characteristics that enable fault management and that addresses many aspects of the problems listed above. We first describe our design and then explain its suitability for fault management. 3. 1 Description The architecture we use is known as data flow or pipe and filter (see e.g. [9]) Well known examples are Unix shells which allow commands to be connected by pipes, image processing frameworks where images flow through several filters, routers that forward data through a network, E mail relays forwarding messages, and so on. This architecture is based on interconnected ....

....Programming, dpunkt Verlag, Heidelberg, 1997. 8] E. Solana, V. Baggiolini, M. Ramluckun and J. Harms, Automatic and Reliable Elimination of E mail Loops Based on Statistical Analysis , in Proceedings of the 10th Usenix Systems Administration Conference (LISA 96) Chicago, September 1996. [9] D. Garlan, M. Shaw, An Introduction to Software Architecture , Carnegie Mellon University Technical Report CMU CS 94 166, January 1994. 10] B. Meyer, Applying Design by Contract , IEEE Computer, Vol. 25, No. 10, pp. 40 51, October 1992. 12 Adapting Object Oriented Components Jan Bosch ....

[Article contains additional citation context not shown here]

Mossenbock, H.: The Programming Language Oberon-2. Structured Programming 12:4, 1991.

....are inherited in type extensions unless they are overridden by a new implementation (under the same name and with the same parameter list) Within the scope of the new implementation, the original version can be identified by adding a to its name. This notation is borrowed from Oberon 2 [6], where it is used for a similar purpose. 2. Within the scope of a record type, unqualified) names of its variables and procedures always refer to components of the current object. The current object as a whole is denoted in the record scope by the new keyword self. 3. The section keyword ....

H. Mossenbock, N. Wirth, The Programming Language Oberon-2, Structured Programming, 12, 179-95.

....have more than one participant gives us a mechanism for expressing n ary communication between objects. By showing how type bound actions can logically be reduced to plain actions, we give our extension a firm foundation in the Refinement Calculus. 1 Introduction Action Oberon extends Oberon 2 [22] with actions for modeling parallel and distributed computations. The extension is based on the theory of action systems [6] and was proposed by Back and Sere [8] and implemented by Hedman [14] An action system is a parallel or distributed program where parallel activity is described in terms of ....

....of type bound actions and the deallocation of objects, Sect. 5 discusses inheritance of type bound actions, Sect. 6 provides a foundation for type bound action in the Refinement Calculus, Sect. 7 points to related work, and Sect. 8 draws the conclusions. 2 Action Oberon Base Language Oberon 2 [22] is the successor of Pascal and Modula 2. Modula 2 adds modularization to Pascal. Oberon 2 extends Modula 2 with object oriented concepts in form of type extension on record types (subtyping inheritance) as well as type bound procedures (methods) Oberon 2 has been chosen as a base language ....

P. Mossenbock and N. Wirth. The programming language Oberon-2. Structured Programming 12:179--195, 1991.

....delinearization of its own data. As a specific example, we describe how the framework is used to provide the basic communication facilities used in the Hermes system [Lal94] a framework supporting extensible distributed programming. The system is implemented in the Oberon 2 programming language [MW91] on the Concurrent Oberon system [LS94] a version of the Oberon system with support for concurrency. 2 A General Framework For Data Structure Transfer In this section, we describe the basic support for transfer 1 of dynamic data structures, i.e. structures made up of records connected by ....

Hanspeter M¨ossenb¨ock and Niklaus Wirth. The programming language Oberon-2. Structured Programming, 12(4):179--195, 1991.

.... implementations might even be changed during an object s life time) but less economic memorywise (one memory word is used per method and object) In passing we note that class wide methods are offered under the name of type bound procedures by a variant of the Oberon language called Oberon 2 [2]. The problem with the Oberon 2 solution is a stylistic inconsistency originating from the fact that (in contrast to record components) type bound procedures are overwritable in derived types and thus reintroduce all the problems of method inheritance through the backdoor. In the section on active ....

H. Mossenbock and N. Wirth. The Programming Language Oberon-2. Structured Programming, 12(4): 179-195, 1991.

....The method table is simply a vector of function pointers and unique method identifiers. The method identifiers are used when invoking interface functions, which must be found at run time. The structure of the method table is typical of statically bound object oriented languages like Oberon 2 [MW91] and C [Str86] Method tables include inherited methods as well as functions defined by the class itself. Proceedings of the Third Conference on Object Oriented Technologies and Systems (COOTS 97) 3 Object Pointer Object Instance Instance Variables Class Struct Array Bit = 0 Instance Size . ....

H. Mossenbock and N. Wirth. The programming language Oberon-2. Technical report, Institute for Computer systems, ETH, 1991.

....The method table is simply a vector of function pointers and unique method identifiers. The method identifiers are used when invoking interface functions, which must be found at run time. The structure of the method table is typical of statically bound object oriented languages like Oberon 2 [MW91] and C [Str86] Method tables include inherited methods as well as functions defined by the class itself. Object Pointer Object Instance Instance Variables Class Struct Array Bit = 0 Instance Size . Figure 1: Ordinary Object Structure Object Pointer Array Instance Length . Class ....

H. Mossenbock and N. Wirth. The programming language Oberon-2. Technical report, Institute for Computer systems, ETH, 1991.

....the result of removing features from Modula 2, however a few features were added. The most important addition is type extensions [19] which provide basic support for inheritance. Oberon has evolved into Oberon 2, the most recent of the Oberon languages, and is described by Mossenbock and Wirth [9]. Oberon 2 was influenced by Object Oberon [8] and incorporates type bound procedures, which are equivalent to methods. Type extensions and type bound procedures provide the support for object oriented programming generally provided by explicit classes in object oriented programming languages. As ....

Hanspeter Mossenbock and Niklaus Wirth. The programming language Oberon-2. Structured Programming, 12:179--195, 1991.

....be inherited in the opposite direction from subtyping if desired. 2. 3 Separating Subtyping and Subclassing Traditionally, object oriented languages are either untyped e.g. Smalltalk [10] or Self [27] or tightly bind classes and types e.g. C [8] Eiffel [17] Modula 3 [21] or Oberon 2 [19]. In contrast to Oberon 2, Oberon [23] keeps the dispatching of implementation variants separate from subtyping issues, essentially by not providing methods at all. Instead, Oberon relies entirely on procedure variables to implement late binding. Nevertheless, Oberon still does not completely ....

Hanspeter Mossenbock and Niklaus Wirth. The programming language Oberon-2. Structured Programming, 12(4), 1991.

Online articles have much greater impact   More about CiteSeer.IST   Add search form to your site   Submit documents   Feedback  

CiteSeer.IST - Copyright Penn State and NEC