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.

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.

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.

First 50 documents

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