A concurrent object-oriented extension to the programming language Scheme, called Schematic, is described. Schematic supports familiar constructs often used in typical parallel programs (future and higher-level macros such as plet and pbegin), which are actually defined atop a very small number of fundamental primitives. In this way, Schematic achieves both the convenience for typical concurrent programming and simplicity and flexibility of the language kernel. Schematic also supports concurrent objects which exhibit more natural and intuitive behavior than the "bare" (unprotected) shared memory, and permit intra-object concurrency. Schematic will be useful for intensive parallel applications on parallel machines or networks of workstations, concurrent graphical user interface programming, distributed programming over network, and even concurrent shell programming.

Dynamic binding is a runtime operation which looks up some names in some environments: examples are quote and eval in LISP or object-oriented message passing. We present a functional language, in the spirit of ML or Haskell, which supports dynamic binding. At the surface level, the language supports constructs such as extensible records, variants, extensible case selection, quoted terms, and can encode various forms of objects. The underlying execution model is a lambdacalculus with name-based (labels, keywords) parameter passing. The type system supports subtyping, through an extension of Hindley-Milner type inference with recursively constrained types. keywords: functional, object-oriented, subtyping, record concatenation, quoting, environments, contexts 1 Introduction Dynamic binding denotes a family of programming constructs where the runtime system includes some notions of "names" and "environments" (associations from names to values) , and where the operation of looking up some...

. The search for a language which combines both functional and object-oriented features has a long and distinguished history [15, 16, 10, 8, 9, 34, 6, 17, 33, 39, 19]. The aim is to integrate the formal methods benefits of functional programming with the software engineering benefits of both paradigms. However, to date we know of no language which can claim to be both purely functional and purely object-oriented (and retains complete type safety). We present CLOVER, a new language which is 100% functional and 99% object-oriented. It is also completely type safe. We explain the design issues and how CLOVER achieves its aim. We also explain the "missing" 1%, discuss its relevance, and illustrate how its loss can be extenuated through the use of a new visual programming notation. 1 Introduction The object-oriented (OO) paradigm, together with an appropriate methodology, has successfully delivered many large projects. OO design (OOD) is used extensively in industry since it provides good ...

This paper presents the case for a run-time operating system to provide predictable and controllable resource management for parallel applications. Developments in compilers for parallel applications, which depend on analysis of program behaviour, require corresponding developments in predictable and controllable operating systemlevel resource management. A customisable system, Arena, is described which provides operating system-level resource management at user-level, where it is accessible to application and run-time system developers. This resource management is accessed via libraries, and effectively becomes part of the application run-time system. In such a system the application gets only the resource management that it needs. A low-policy hardware-dependent executive provides a lowlevel interface presenting an abstraction of processor hardware to the hardware-independent resource managers. The use of Arena on a Sparc-based distributed store multicomputer is described, and three...

. This paper concentrates on the search for a programming language and supporting theory which combines features from the objectoriented and functional paradigms. The aim is to integrate the formal methods benefits of functional programming with the software engineering benefits of both paradigms. In this paper, which derives from the author's recently-published paper [CB96], we first discuss related work and identify the research problems. We then present our solutions and contribution to this field, CLOVER, a completely type-safe language which is 100% functional and 99% object-oriented. Finally, we explain how the "missing 1%" represents the core incompatibility which can be extenuated by supplying new interpretations and a new visual programming notation. 1 Introduction The object-oriented (OO) paradigm, together with an appropriate methodology, has successfully delivered many large information systems. OO design (OOD) is used extensively in industry since it provides good control...

this paper our aim is to show how the benefits of object-oriented methodologies can be realized within the framework of functional programming, achieving a more powerful level of modular program structure and avoiding introduction of the possibility of nondeterminate program behavior except when demanded by an application. We show how inheritance can be supported by an extension of the Sisal language, namely ObjectSisal, to include a natural class mechanism with immutable abstract data types, and how uses of "state" may be handled by means of stream data types and the nondeterminate merge operation. These principles are illustrated using examples from simulation and real-time systems. We believe that efficient distributed implementation of such an object-oriented methodology can be achieved through compile-time program transformation and execution platforms that implement fine-grain threads.

this paper we use TGRS and we exploit the high degree of fine grain parallelism available in the model in expressing a variety of concurrent object-oriented programming techniques. Being our framework language independent, it can serve as a basis for designing new concurrent Concurrent OOP using TGR techniques: George A Papadopoulos 2 object-oriented languages, implementing existing ones or act as a point of reference in comparing different approaches proposed by various languages to modelling certain OOP techniques such as delegation, inheritance, etc. but also to solving any associated problems encountered

This report motivates and defines a general-purpose, architecture independent, parallel computational model, which captures the intuitions which underlie the design of the United Functions and Objects programming language. The model has two aspects, which turn out to be a traditional dataflow model and an actor-like model, with a very simple interface between the two. Certain aspects of the model, particularly strictness, maximum parallelism, and lack of suspension are stressed. The implications of introducing stateful objects are carefully spelled out. The model has several purposes, although we largely describe it as it would be used for visualising the execution of programs. The model is embodied in a textual intermediate format, and in a set of UFO data structures. This report also serves as a definition of the intermediate format, and gives a brief overview of the data structures. 1 Introduction This report serves two purposes. Firstly, in sections 1 to 9, the Uflow computational...

This report motivates and defines a general-purpose, architecture independent, parallel computational model, which captures the intuitions which underlie the design of the United Functions and Objects (UFO) programming language. The model has two aspects, which turn out to be a traditional dataflow model and an actor-like model, with a very simple interface between the two. Certain aspects of the model, particularly strictness, maximum parallelism, and lack of suspension are stressed. The implications of introducing stateful objects are carefully spelled out. The model has several purposes, although we primarily describe it as a vehicle for the compilation and optimisation of UFO, and for visualising the execution of programs. Having motivated the model, this report specifies, in detail, both the syntax and semantics of the model, and provides some examples of its use. 1 Motivation The primary purpose of this report is to define the semantics and syntax of NewFLOW, an intermediate rep...

Introduction Our new language ABCL/f , which is a descendant of ABCL/1 [12], is an explicit parallel language and based on a notion of concurrent objects. Unlike the original ABCL/1, however, it is not monolithically concurrent object-based. It allows usual function/procedure invocations as well as method invocations. One of the major difficulties in parallel programming is safe and efficient access to shared mutable data structures. In order to alleviate this difficulty, our language enforces programmers to define classes of concurrent object in order to use and encapsulate shared mutable data structures. Immutable data structures, however, are defined as ordinary data types and need not be defined as concurrent objects. The fundamental reason to write parallel programs is to exploit parallelism not only for more computational power, but also for fast, yet natural problem solving. Our language is intended to be