N. Wirth, `The programming language Oberon', Software---Practice and Experience, 18, 671--690  Home/Search   Document Not in Database   Summary   Related Articles   Check

....language concepts such as subtyping between type operators, recursive type operators, extensible record values, and hbraries as scopes for modules and interfaces. The syntactic structure and the module concept of Tr are similar to those of the languages of the Modula family (Modula 2 [12] Oberon [26], Modula 2 [23] Modula 3 [22] and Add [11] Regarding its semantics, Tr is more closely related to the polymorphic functional languages of the ML language family [5, 6, 19, 8, 10] The semantic concepts of Tr are derived from the language F [7] a widely accepted formal basis for the study of ....

N. Wirth. The programming language Oberon. Technical report, Department Informatik, ETH Ziirich, Switzerland, 1987.

....able to establish that correctness. Gardens Point Component Pascal (gpcp) is a compiler for the whole of the language Component Pascal[4, 5] All of the issues listed above needed to be resolved, in order to achieve this outcome. 1. 3 Why Component Pascal Component Pascal is a dialect of Oberon 2[6, 7]. 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. Its ancestors are Oberon, Modula 2 and Pascal. As a vehicle ....

N. Wirth, `The Programming Language Oberon'; Software Practice and Experience 18:7, 671{ 690; 1988.

....pillar of object orientation. Only because an object s client does not depend on one specific implementation, it can work with instances of subclasses as well. Syntax level encapsulation is provided by most OOP languages, for example, C [51] Eiffel [34] and Java [22] Modula 3 [41] Oberon [57], and Component Pascal [43] combine object orientation with modules. As a combination of modular and object oriented programming, component software relies on encapsulation and abstraction as well [53] and again, syntax level abstraction is supported by interface description languages (IDLs) as ....

Niklaus Wirth. The programming language Oberon. Software -- Practice and

....are needed. The added safety, brought by the validation of the programming invariant at run time, more than compensate the penalty paid in the execution time. In fact, there is no acceptable trade off for letting a type violation be passed. The programming language chosen for XO 2 is Oberon 2 [5]. Oberon is a successor of Pascal and Modula, featuring strong typing, compatibility by name and not by structure, object orientation, and modularisation. Since the same characteristics are shared by the Java programming language, an ongoing effort aims at supporting the language, by natively ....

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

....of our work is to improve on the execution model of modular software. We do not attempt to devise any new programming models, but leave this task to others. However, by basing our work on a modular system, namely the Oberon System [1] we give it a firm foundation with adequate language support [2] that may well turn out to be wholly sufficient for most component oriented software architectures. 2 An Architecture Centered Around Run Time Code Generation In an ideal component oriented system, software distribution should have the following properties: It should be instantaneous, i.e. ....

Wirth, N: "The Programming Language Oberon"; Software-Practice and Experience, 18:7, 671-690; 1988.

....a highly dynamic software environment in which executing code can be extended by further functionality at run time. The unit of extensibility in Oberon is the module; modules are composed, compiled and distributed separately of each other. Oberon is programmed in a language of the same name [Wirth 1988], a direct successor of Pascal and Modula 2. The Oberon System is available on a wide variety of platforms [Franz 1993, Brandis et al. 1995] For all practical purposes, Oberon s modules supply exactly the functionality that is required for modeling mobile components. Modules provide ....

N. Wirth (1988); "The Programming Language Oberon"; Software-Practice and Experience, 18:7, 671-690.

....our concern for modular verification, but the possible scopes they consider are not rich enough to allow subclasses or the RdRep interface of our example. Another, rather different, approach of hiding information is to classify declarations as public or private. This approach is used in Oberon [49], C [11] and Java [15] In the course of the ESC Java project [13, 32] we used the modularity requirements of the units approach to guide our design for visibility of invariants in the public private approach [33] One of the central ideas of this paper, explicit dependency declarations, were ....

N. Wirth. The programming language Oberon. Software---Practice & Experience, 18(7):671--690, July 1988.

....states of such a system are decentralized, and the overall current state of the system is the union of the current states of the component TASMs. The speci cation of such a system is a kind of speci cation in the large. Special means like those existing in some programming languages (e.g. Oberon [4] and Ada [5] and speci cation languages (e.g. Extended ML [6] and CASL [3] are to be elaborated for creating bigger TASMs from smaller ones. The following structural mechanisms are investigated in this paper: 1. Use of existing TASMs when constructing a new one. The components of an existing ....

....of the models (TASMs) of the imported modules. An imported name can be referenced in one of the following ways: 1) directly with a possible quali cation in case the name is overloaded; 2) pre xed with the name of the module where it is originally de ned as it is done for modules in Oberon [4] or some other programming languages. The direct use of an imported name is not possible, however, when it is declared with the same pro le in two or more modules. The name initialize in the modules StackOfOper and IdT able can serve as an example. Therefore, we prefer the second way, i.e. pre ....

N. Wirth. The Programming language Oberon (Revised edition). Departement Informatik, Institute for Computersysteme, ETH, Zurich, 1990.

....memory performance specifically for pointer centric applications. Our optimization is based on determining the best internal storage layout for dynamically allocated data structures. It applies to programming languages that are fully type safe, such as Java [Gosling et al. 1996] and Oberon [Wirth 1988]. These languages do not permit programmers to make any assumption about the internal storage layout of the data structures they declare; as a consequence, choosing such an internal layout lies completely in the domain of the compiler. Our technique strives to maximize spatial and temporal ....

....to test our results, we have used a nonstandard suite of programs, all of which make extensive use of dynamically allocated data structures. Our benchmark suite includes our optimizing compiler as an example of a non trivial program. This optimizing compiler (for the programming language Oberon [Wirth 1988] and the PowerPC target architecture) allocates large dynamic data structures that model the program being compiled in a variant of static single assignment form [Brandis 1995; Cytron et al. 1991] The Case for Dynamic Optimization 11 Benchmark Program Size Number of Al Number of Al Average ....

Wirth, N. 1988. The Programming Language Oberon. Software Practice and Experience 18, 7 (July), 671--690.

....memory performance specifically for pointer centric applications. Our optimization is based on determining the best internal storage layout for dynamically allocated data structures. It applies to programming languages that are fully type safe, such as Java [Gosling et al. 1996] and Oberon [Wirth 1988]. These languages do not attach a semantic meaning to the declaration order of data members and do not expose the actual physical layout to the programmer; as a consequence, choosing an internal layout lies completely in the domain of the compiler. Our technique strives to maximize spatial ....

....to test our results, we have used a nonstandard suite of programs, all of which make extensive use of dynamically allocated data structures. Our benchmark suite includes our optimizing compiler as an example of a non trivial program. This optimizing compiler (for the programming language Oberon [Wirth 1988] and the PowerPC target architecture) allocates large dynamic data structures that model the program being compiled in a variant of static single assignment form [Brandis 1995; Cytron et al. 1991] For the compiler benchmark, we only give ideal speedup results. Our optimizer processes code that ....

Wirth, N. 1988. The Programming Language Oberon. Software Practice and Experience 18, 7 (July), 671--690.

....performance specifically for pointer centric applications. It is based on determining the best internal storage layout for dynamically allocated data structures and applies to programming languages that are fully type safe. Examples of such languages include Java [Gosling et al. 1996] and Oberon [Wirth 1988]. These languages do not attach a semantic meaning to the declaration order of data members and do not expose the actual physical layout to the programmer; as a consequence, choosing an internal layout lies completely in the domain of the compiler. The technique strives to maximize spatial ....

Wirth, N. 1988. The Programming Language Oberon. Software Practice and Experience 18, 7 (July), 671--690.

....Santa Clara, CA 95054; M. Franz, Department of Information and Computer Science, University of California at Irvine, Irvine, CA 92697 3425. ACM Transactions on Programming Languages and Systems, Vol. TBD, No. TBD, TBD TDB, Pages 1 . 2 T. Kistler and M. Franz [Gosling et al. 1996] and Oberon [Wirth 1988]. These languages do not attach a semantic meaning to the declaration order of data members and do not expose the actual physical layout to the programmer; as a consequence, choosing an internal layout lies completely in the domain of the compiler. Our technique strives to maximize spatial ....

....to test our results, we have used a nonstandard suite of programs, all of which make extensive use of dynamically allocated data structures. Our benchmark suite includes our optimizing compiler as an example of a nontrivial program. This optimizing compiler (for the programming language Oberon [Wirth 1988] and the PowerPC target architecture) allocates large dynamic data structures that model the program being compiled in a variant of static single assignment form [Brandis 1995; Cytron et al. 1991] The other benchmarks are TreeAdd and Bisort from the Olden benchmark suite [Rogers et al. 1995] ....

Wirth, N. 1988. The Programming Language Oberon. Software Practice and Experience 18, 7 (July), 671--690.

....class objects. The operator , applied to a routine or an attribute, returns an object of type feature model; this class is the general modeling of a feature. Such a mechanism provides for routine variable manipulations and activations as in structured languages (for instance Clu [18] Oberon [23]) In object oriented programming it corresponds to a meta level, and more precisely a message reification [8, 9] There are two different settings for an exception: ffl continue: execute a specific handler and resume the previous action. ffl ignore: ignore the exception. 3 class REQUEST ....

Wirth, N. "The programming Language Oberon", Software-Practice & Experiences, V18.7, 1988. 19

....of data re nement is shown in Section 8, using couplings de ned in Section 7. Section 9 extends the language to include extensible records, and extends the above results. Applications are in Section 10 and concluding remarks in Section 11. A less condensed presentation of our idealized Oberon [Wir88], called Io after another planetary moon, can be found in [Nau00] An introduction to data re nement can be found in, e.g, Mor94] a clear and concise account appears in [Ten94] which also explains a semantics that can be used to show soundness of data re nement in an Algol like language. 1 ....

N. Wirth. The programming language Oberon. Software { Practice and Experience, 18(7), 1988.

....of a type conversion function (SHORT) since the programmer has to ensure that the conversion is legal, i.e. A Language Proposal that the value of an expression of the larger type is also comprised by the smaller type. The main reason for having several integer or real types is storage economy [Wirth 1990]. In general, the use of different integer or real types within a single expression is not recommended: in such mixed type expressions, determining the exact operations performed requires a careful and toilsome analysis of the expression. Often additional LONG or SHORT functions are required to ....

....System. Warren, H. S. Jr. 1990] Instruction Scheduling for the IBM RISC System 6000 Processor , IBM Journal of Research and Development, 34:1 (January) 85 92. Winston, P. H. and B. K. P. Horn [1984] Lisp, 2nd edition, Addison Wesley. Contains a definition of the notion side effect . Wirth, N. 1971] The Programming Language Pascal , Acta Informatica, 1, 35 63. Wirth, N. 1972] On Pascal , Code Generation, and the CDC 6000 Computer, Technical Report STAN CS 72 257, Computer Science Departement, Stanford University. Wirth, N. 1985a] Programming in Modula 2, Springer, third ....

[Article contains additional citation context not shown here]

Wirth, N. [1988a]. "The Programming Language Oberon", Software - Practice and Experience, 18:7 (July), 671-690.

....its predecessor when compiled by itself, while it runs almost as fast. Keywords: Software Engineering, Compilers, Optimization, Programming Languages, Oberon. 1. Introduction The Spirit of Oberon can be summarized by the guiding principle of making it as simple as possible, but not simpler [Wir88, WG89]. Optimizing compilers, on the other hand, are characterized by an enormous and ever increasing complexity. As their authors keep on adding functionality for handling even rarely occurring constructs, these compilers grow to immense sizes while being slowed to appalling levels of performance. Were ....

N. Wirth; "The Programming Language Oberon"; Software-Practice and Experience, 18:7, 671-690; 1988.

....Cedar allowed users to change or add system features via extensions. Extensions in Cedar and other systems are externally de ned modules that extend or modify the behavior or available functionality of a system. Other extensible systems include SPIN [9] the HotJava WWW browser [42] Oberon [52] and even the Emacs editor [41] While 2 web browsers and text editors are not operating systems in a traditional sense, both of these systems may need to manage and control their extensions in the same manner as an operating system. Software based protection mechanisms are also useful in systems ....

Wirth, N. The programming language Oberon. Software|Practice and Experience 18, 7 (1988), 671-690.

....was the package. Unfortunately, packages (unlike tasks) were not fully integrated into the typing model: there were no package types. Rather than introduce a class like construct into the language (as had been done by almost all other object oriented languages) Ada 95 followed the Oberon (Wirth, 1988) approach and achieved object orientation by type extension. The designers argued that Ada 83 already had the ability to derive types from other types and override their operations. Consequently, object orientation was achieved via the introduction of tagged types . Tagged types in Ada 95 are ....

Wirth, N. (1988). The programming language Oberon, Software - Practice and Experience 18(7): 671--690.

....language fit this general description are (a) some kind of class structure, with inheritance (b) some means for dynamically binding methods to objects based on runtime tests of object class Oberon 2 [3, 4] is a minimal language which provides these features. Oberon 2 is an extension of Oberon [5] the main feature of which is type extension [6] Oberon, in turn, was based on Modula2 [7] Object oriented languages of this kind seem to us to be natural vehicles for the implementation of software systems based on abstract syntax tree (AST) representations. We are therefore interested in ....

Wirth, N., "The Programming Language Oberon", Software Practice and Experience, Vol 18, No 7, pp 671-690, July 1988.

....increases cache performance specifically for pointer centric applications. Our optimization is based on determining the best internal storage layout for dynamically allocated data structures. It applies specifically to programming languages that are fully type safe, such as Java [AG96] and Oberon [Wir88]. These languages do not permit programmers to make any assumption about the internal storage layout of the data structures they declare; as a consequence, choosing such an internal layout lies completely in the domain of the compiler. Our technique strives to maximize spatial and temporal ....

....to test our results we have used a nonstandard suite of programs, all of which make extensive use of dynamically allocated data structures. Our benchmark suite includes our optimizing compiler as an example of a non trivial program. This optimizing compiler (for the programming language Oberon [Wir88] and the PowerPC target architecture) allocates large dynamic data structures that model the program being compiled in a variant of static single assignment form [CFR 91] The other benchmarks are Layouts, an interpreter for a batch processing language that composes interactive graphical user ....

N. Wirth. "The Programming Language Oberon". Software-Practice and Experience, 18:7, 671-690; 1988.

....ColorPoint to illustrate the naive encoding of objects that first comes to mind. Since we do not have subtyping, this solution works. If a method of some class wants to access or modify some of its methods, it takes itself as an explicit argument. This is similar to type bound procedures in Oberon [27], where class methods take the receiver object as an explicit argument. In Mondrian, we write: class Point where pos : Int,Int) pos = 0,0) move : Point (Int,Int) Point ; move this (x,y) pos (dx,dy) this pos = x dx,y dy) If we later extend Point to ColorPoint by adding a ....

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

....expressions, they should be free of side effects. Unfortunately most procedural programming languages do not support side effect free functions. In these languages, a function is nothing else but a procedure that specifies a return value. Therefore, sometimes the term function procedure is used [7]. Because procedures can have side effects (it is their very purpose) they are usually allowed in function procedures, too. Thus, expressions are not always side effect free in these languages. On the other hand, if functions are generally side effect free, expressions are always side effect free ....

....methods (for instance together with a stop and compact garbage collector that allocates variables consecutively) However, we have not yet investigated such techniques. We have implemented a simple version of the birthdate method in a compiler for a subset of the programming language Oberon [7]. Every dynamic variable contains an additional time stamp field for the birthdate, no redundant checks are eliminated and no clock resetting is done. The implementation effort for integrating side effect checks into the compiler was around a dozen lines of code. The compiler first generates an ....

[Article contains additional citation context not shown here]

Wirth, N. (1988). "The Programming Language Oberon", Software - Practice and Experience, 18:7 (July), 671-690.

....demonstrate its application to type analysis and optimization presenting several variants, whose power is demonstrated by an illustrating example. Section 6, finally, contains our conclusions. 2 The Language SimpleOberon Like in [CG94] we consider an Oberon 2 like programming language (cf. [MW91, Rei91, Mos95]) called SimpleOberon, which omits complex data structures like arrays or multilevel pointer structures, but is complex enough to demonstrate the essential features of our approach; in particular, of how to resolve the interplay of pointer variables and type bound procedures. The terminology of ....

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

....as the Smalltalk message dispatching mechanism. Objects carry type information at run time which allows dynamic binding of messages, run time type tests, and the implementation of persistent objects. Oberon 2 is available on various machines. OVERVIEW In 1987, Wirth defined the language Oberon [1]. Compared with its predecessor Modula 2, Oberon is smaller and cleaner, and it supports type extension which is a prerequisite for object oriented programming. Type extension allows the programmer to extend an existing record type by adding new fields while preserving the compatibility between ....

Wirth, N "The Programming Language Oberon" Software Practice and Experience, Vol 18, No 7, (July 1988), pp 671-690.

.... is the applet developer that needs to make this choice; the end user need not know any of it as multiple mobile code technologies, such as Java and Juice, can happily coexist, even on the same web page (Figure 1) 2 PROGRAMMING JUICE APPLETS Juice applets are programmed in the language Oberon [16], a direct successor of Pascal and Modula 2 that was defined by Niklaus Wirth (Pascal s original creator) in 1988. Oberon is surprisingly close to Java in spirit; like Java, Oberon is based on the principles of simplicity and safety. Oberon enforces type safety by mandating arraybounds checking ....

N. Wirth; "The Programming Language Oberon"; Software-Practice and Experience, 18:7, 671-690;

No context found.

Wirth N. (1988) The Programming Language Oberon, Software-Practice and Exprerience 18(7), pp. 671-690.

....our design technique and special requirements lead to a completely different architecture. In fact, our generalizing approach to the design of the framework brings its architecture closer to a framework developed for visual languages [FKP93] The example framework has been implemented in Oberon 2 ([MW91], Ms93] We will deliberately ignore in this paper certain domain specific problems which have been solved in an experimental implementation of the framework [KoM95] A more elaborated language implementation system employing a similar architecture can be found in [JKN95] is implemented by ....

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

....Differences between Oberon and Revised Oberon A revision of Oberon was defined after extensive experience in the use and implementation of the language. Again, it is characterized by the desire to simplify and integrate. The differences between the original version [7] and the revised version [9] are the following: 1. Definition and implementation parts of a module are merged. It appeared as desirable to have a module s specification contained in a single document, both from the view of the programmer and the compiler. A specification of its interface to clients (the definition part) can ....

....the most significant one being the concept of type extension. The evolution of a new language that is smaller, yet more powerful than its ancestor is contrary to common practices and trends, but has inestimable advantages. Apart from simpler compilers, it results in a concise defining document [9], an indispensible prerequisite for any tool that must serve in the construction of sophisticated and reliable systems. Acknowlegement It is impossible to explicitly acknowledge all contributions of ideas that ultimately simmered down to what is now Oberon. Most came from the use or study of ....

N. Wirth. The programming language Oberon (Revised Report). (companion paper) File: ModToOberon2.Doc / NW 1.10.90

No context found.

N. Wirth, `The programming language Oberon', Software---Practice and Experience, 18, 671--690

No context found.

N. Wirth, `The programming language Oberon', Software---Practice & Experience, 18, 670--690 (1988).

No context found.

N. Wirth, `The programming language Oberon', Software---Practice and Experience, 18, 671--690 (1988).

No context found.

N. Wirth, `The programming language Oberon', Software---Practice and Experience, 18, 671--690 (1988).

No context found.

N. Wirth, `The programming language Oberon', Software---Practice and Experience, 18, (7), 671--690 (1988).

No context found.

N. Wirth. The Programming Language Oberon. In Software-Practice and Experience 18(7), pp 671--690, July 1988.

No context found.

N. Wirth, `The programming language Oberon', Software---Practice & Experience, 18, 670-- 690 (1988).

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