Emerald(ID:1320/eme001)
polymorphic object-oriented distributed programming language/environment
Norm Hutchinson U Washington, early 80's.
A polymorphic object-oriented distributed programming language/environment. Strongly typed, uses signatures and prototypes rather than classes and inheritance.
language and programming system providing both process and object mobility on a network of workstations. Objectives- develop and distribute an OOL and system incorporating lightweight object migration, and investigate the issues in using such languages for distributed application development, particularly the areas of reliability and availability.
The EMERALD compiler, which is written in EMERALD, generates byte codes which are then interpreted by a relatively portable interpreter. The interpreter takes care of finding remote objects, performing remote invocations, moving objects, and doing both local and distributed garbage collection.
Structures:
Related languages
| Deltatalk | => | Emerald | Influence | |
| EPL | => | Emerald | Successor | |
| Emerald | => | Amber | Influence | |
| Emerald | => | Green | Influence |
References:
in SIGPLAN Notices 21(11) November 1986 (OOPSLA - Conference on Object Oriented Programming Systems Languages and Applications 1986) view details
in IEEE Trans Soft Eng 13(01) Jan 1987 view details
in IEEE Trans Soft Eng 13(01) Jan 1987 view details
in ACM Transactions on Computer Systems view details
This paper describes the Emerald language and its programming methodology. We give examples that demonstrate Emerald’s features, and compare and contrast the Emerald approach to programming with the approaches used in other similar languages. Extract: Introduction
1. INTRODUCTION
Emerald 1,2 is a strongly-typed programming language that supports an atypical variant of the object-oriented paradigm. Although originally developed to simplify the construction of efficient distributed applications, 3, 4 Emerald provides a generalpurpose programming model. This paper describes the main features of Emerald, comparing and contrasting them with similar features of other languages. Although Emerald may be bracketed with module- or object-based languages, it differs in several ways from other such languages. Unlike Ada 5 or Modula-2, 6 the sole unit of programming is the object, which behaves like a dynamic instance of a Modula-2 module or Ada package. Unlike C++ 7 or Smalltalk, 8 Emerald has no notion of class; Emerald provides object constructors for run-time creation of objects and abstract typing for object classification and comparison. Access to Emerald objects is provided via operations that are invoked by other objects.
Past experience has suggested that language designers must choose between the security and efficiency of static typing and the flexibility of dynamic typing. For example, Smalltalk and Self 9 emphasize flexibility by delaying type checking until run-time, whereas Modula-2 and Ada are statically typed and preclude the safe interaction of existing programs with entities of a new type. Emerald provides both static typing and flexibility using a simple and efficiently-implemented notion of type that allows compile-time checking, polymorphism, encapsulated types and subtyping. A type in Emerald is a collection of operations and their signatures; significantly, a type is itself an object. The Emerald language includes block structure and nesting as found in Simula-67 10 and Beta 11 but noticeably missing from Smalltalk.
Emerald supports the programming of distributed applications by making the invocation of objects independent of their location. Such location-independent object invocation allows the application programmer to treat the distributed system as a single machine. Thus, the Emerald programming model is for the most part nondistributed. This paper focuses on Emerald’s programming model; we will mention Emerald’s distributed upbringing only when motivating the design of some of its features. Several aspects of the distributed nature of Emerald are discussed in the companion paper in this issue. 12
This paper discusses, with examples, the main features of Emerald that help in supporting general-purpose programming. In the next section we describe the Emerald notion of objects, and how they are constructed and used. Section 3 discusses the Emerald abstract type concept and its usage. We then examine the Emerald approach to object-based concurrency, and outline other interesting features of Emerald. Finally, we indicate the current status of our work and summarize its major contributions.
in Software — Practice and Experience 20(01) January 1991 view details
With the advent of workstations and efficient networks, distributed systems are becoming common, and these systems are inherently more complex to program than their centralized counterparts. The additional mechanisms introduced to access information on distant nodes are a major source of complexity.
Within a single address space, procedure call is a well-understood mechanism for the transfer of both control and data. In contrast, messagebased systems require the programmer to deal with the details of message packaging, locating the message target, and asynchronous communication. Remote procedure call (RPC) [4] provides', the familiar procedure call abstraction and hides most of the details of control and data transfer. However, the programmer is still responsible for locating the target of the call. Other problems arise from subtle semantic differences between RPC and local procedure call and because RPC imposes a client/server model on the distributed application [16].
Recently, the object-oriented paradigm has attracted much interest because it achieves data abstraction, software modularity, and code reuse in a natural way. Operations on an object are invoked by sending messages to the object. Thus, communication among objects maps readily to the communication in a distributed system, and local and remote invocation are both syntactically and semantically identical. Since there is no distinction between local and remote objects, it is possible to move objects at run time between the nodes of the distributed system, thus allowing for dynamic load adaptation and reconfiguration.
However, total transparency is not desirable: a few distribution-related features are required to take full advantage of distribution and to tune performance (e.g., to keep related objects close together to avoid remote invocation), but their use can be deferred to a late implementation (preinstallation) phase. Integrating distribution and objectoriented languages has attracted much attention in recent years. Some well-known systems offering both location-independent invocation and object migration are Emerald [5, 6, 10], Amber [7], and Distributed Smalltalk [2, 3, 8, 11].
Extract: Emerald
Emerald is a strongly typed, object-based language. It provides several language constructs to exploit the distributed environment:
? Mobility of objects can be restricted byfixingthem at a node. A fixed object cannot move until it is explicitly unfixed.
? Objects can be attached to other objects. When an object migrates, all mobile objects attached to it will also move. Attachment is transitive but not symmetric.
? Besides passing arguments to an operation by reference, two other mechanisms are available: by-move and by-visit to move the argument object either permanently or temporarily to the invoked object's location.
Extract: Amber
Amber augments a subset of C + +
with primitives to manage concurrency
and distribution. The system is
designed to maximize performance by
exploiting concurrency in relatively
short-lived applications. To
accomplish this, Amber provides a
networkwide shared virtual memory.
There are no declarative mechanisms
available to control object mobility or
to specify which objects ar6 related;
however, objects can be attached at
run time.
in [ACM] CACM 36(09) (Sep 1993) view details
in [ACM] CACM 36(09) (Sep 1993) view details
in [ACM] CACM 36(09) (Sep 1993) view details
in [ACM] ACM Computing Surveys (CSUR) 30(2) June 1998 view details
GroupLog defines extensions to the Extended Horn Clause
language (EHC) [29], that are supported at two levels: L1,
defines agents as program units and L2 defines groups of agents.
A GroupLog system contains concurrently executing
agents able to: (1) communicate through interface predicates,
and (2) join groups to coordinate their activities. In
the following, we first summarize EHC (see [29]), and then
describe the two mentioned levels. Extract: GroupLog and other work
Related Work
Recently, models have been proposed based on coordination concepts aiming at integrating a number of components together such that the collective set forms a single application that can take advantage of distributed systems.
Many proposals extend a base logic language for concurrency, communication and non-determinism. The base language may be Horn Clause Logic, Temporal Logic, Linear Logic or Situation Calculus. In the first case, we have Rose, DeltaProlog, MultiProlog. In the second, MetaTem. In the third, COOL and IAM and in the last case ConGolog. Specification of concurrency has also been introduced jointly with an objectoriented model such as in DLP, CSO-Prolog, ShaDE, IAM and COOL.
The motivation to use EHC as the base language for GroupLog is due to its elegant interpretation of a process interaction and its rigorously defined semantics. The dynamic entities of a program can be modeled by: Processes, as April and MultiProlog; Objects, as ShaDe, Law Governed Linda, IAM, ColaS, Electra and Emerald; Agents, as ConGolog, COOL, MetaTem, Agentspeak, 3APL and Placa; Actors, as Concurrent Aggregates and Synchronizers.
The interation between dynamic entities can be modeled by: Sending messages, as ShaDe, ConGolog, Concurrent Aggregates, IAM, AgentSpeak, COOL, MetaTem, April, Placa and Electra; Shared tuples, as GammaLog, PollS, Law-Governed Linda, MultiProlog and ESP.
L1 vs others models
In L1, we structured the concurrency and communication with the agent notion, but this language does not aim to provide a theory to model the mental state of an agent, as in MetaTem, ConGolog, AgentSpeak, 3APL and Placa. The agent behavior is only dependent on the interface predicates and its configuration, i.e. the entities are reactive and act in accordance with the interaction and its configuration, like in the actor model. This behavior is modeled by EHC clauses, with a very similar interpretation to the rule based one in AgentSpeak and 3APL. In L,, one simple form of communication is allowed: the explicit invocation of interface predicates. The notion of agent in L, integrates the logic aspect with the object-oriented model, as in [11]. In this model it is possible to model blackboardbased systems, which is only allowed in GroupLog in L2.
L2 vs others models
The definition of groups in GroupLog was the result of an incremental development process which started with our early experimentation with the ISIS system. Groups allow the modeling of a cooperative entity and the dynamic evolution of a system. A group can be created or destroyed, as its members can join or leave the group at any time. The group members are hidden from the outside environment. Because a group is a meta-agent, it is possible to have a group as a member of another group, so this allows the composition of the group notion, as the context notion defined in [7]. In a group we allow two forms of communication: by invocation of interface predicates or through the shared group state. So, L2 is also an experiment towards unifying distributed-memory (remote predicate call) and shared-memory models (shared data). In some of programming languages, like MetaTem, COOL and Concurrent Aggregates, the group notion is used to restrict the communication to a certain group of agents, which may alleviate some of the inefficiencies that occur in full broadcasting.
In other languages, like Electra, Emerald, Synchronizers and Colas, the group is seen as a logical unit that manipulates and restricts the invocation of the members group interface. In Syneronisers, the notion of coordination is modeled by a special object (synchroniser) that restricts the invocation of the group of objects using constraints. In most of these programming languages, as in GroupLog, the group is a dynamic entity. But in Synchronizers and Colas it is possible to dynamically change the coordination behavior, which is not possible in GroupLog.
In GroupLog, as in Electra and Emerald, the members of the group perceive a consistent view of: (1) the other agents who are also part of the group and (2) the shared state.
The main difference between GroupLog and these languages is the group interface predicates, that may be distinct from the group members individual interface. In languages where the communication is modeled by shared-memory, like ESP and PoliS, the communication structuring is done by allowing multi-tuple spaces. In ease of PoliS there are hierarchical tuple spaces. The L2 level of GroupLog supports the structuring of the tuples space into multiple parts, as each is naturally encapsulated within a specific group such that only its members are allowed to access the group state.
This is a good approach to address both modularity, information-hiding, and scalability concerns in large-scale real applications.
in Proceedings of the 2000 ACM Symposium on Applied computing SAC'2000 Villa Olmo, Como, Italy view details
in Concurrency: Practice and Experience 2000 v12 view details
Resources
hme page for Emeraldexternal link