PLASMA(ID:688/pla018)PLAnner-like System Modeled on Actors. Carl Hewitt, 1975. The first actor language. Originally called Planner-73, and implemented in MacLisp. Lisp-like syntax, but with several kinds of parentheses and brackets. Structures: Related languages
References: The ACTOR Model of Computation The actor model of computation consists of four tightly related and mutually consistent components: A method for the rigorous behavioral specifications of actors at various levels of detail. An important degree of flexibility available in actor semantics involves the amount of detail to be included in specifications. That is, an actor can be specified (or its set of possible behaviors can be specified) in as much or as little detail as is desired. To specify desired behavior of a system one can write axioms which any behavior of the system must satisfy. At a very high level of detail these axioms will essentially be input-output constraints, i.e. what is to be done, not how. If more detailed specifications are made, the possible behaviors which will realize those input-output constraints become more restricted. We need an "eclectic magnifying glass" which enables us to look at computations and see only the relevant details. Generally, in order to prove that a set of specifications is satisfied by a particular system, one examines the behaviors of the system at a level of greater detail than that of the specifications and proves that these behaviors realize the behavior that is required. An unbiased mathematical theory of computation which can represent any kind of discrete behavior that can be physically realized. Our goal is to have a robust theory whose theorems are not sensitive to arbitrary conventions and definitions. We need a formalism which will be widely applicable as a mathematical tool for formalizing and investigating properties of procedures. Event Diagrams which are a graphical notation for actor computations which represents the relationship between the events that occur in the middle of actor computations. Event diagrams graphically illustrate the causal structure of the events that occur in a computation and also make explicit the knowledge relationship between the actors in the computation. A modular formalism (called PLASMA for PLAnner-like System Modeled on Actors) based on actor semantics in which to write programs. Actor semantics was not developed to explain or define PLASMA [ which is also called PLANNER- 73 ] . PLASMA is a system dedicated to the direct realization of this semantic base. PLASMA attempts to achieve the following goals: For any given piece of knowledge there is a natural place in the formalism to incorporate the knowledge so that it will be used when it is appropriate and not used when it is inappropriate. As much knowledge as desired can be put in any actor. A system can be directly programmed without circumlocution once the behavior of objects and the messages passed between them has been specified. As many properties as possible of the behavior of an actor implemented in PLASMA should be manifest in the structure of the code. This paper demonstrates how actor message passing can be used to understand control structures as patterns of passing messages in serial processing. This paper is a pre-requisite for successors which treat issues of parallelism and communication within the framework established here. The ability to analyze or synthesize any kind of control structure as a pattern of passing messages among the members of a society provides an important tool for understanding control structures. Ultimately, we hope to be able to characterize various control structures in common use by societies b terms of patterns of passing messages. This paper makes a small step in this direction by showing how to characterize familiar control structures such as iteration and recursion in these terms. External link: Online copy at MIT Extract: PLASMA A system (called PLASMA for PLANNER-like System Modelled on actors) implemented in terms of actor message passing that is convenient for the interactive construction of scenarios, scripts, and justifications. A SCRIPT is a PLASMA program which can be used to specify the action that an actor will take when it receives a message. In our research we have attempted to investigate semantic instead of syntactic issues. We have designed PLASMA to be a transparent medium for expressing the underlying semantics of actor message-passing. For example the semantics of the "knows-about" relationship for actors dictates that PLASMA must use a particular syntactic rule (lexical binding) for the referents of identifiers. The semantic model specifies that acquaintances of an actor must be specified when the actor is created. PLASMA satisfies this semantic constraint by using the values of the identifiers at the time of creation for the free identifiers in the script of a newly created actor since these are the only actors available to be used as acquaintances. Extract: Event diagrams The Event Diagrams presented in this paper are a further development of a graphical notation used by Richard Steiger In his masters thesis for displaying relationships among the events of an actor computation. In this paper we use them to show the causal and knowledge relationships that characterize simple control structures such as iteration and recursion as patterns of passing messages. Given an outline of important hypothesized events and causal relations among the events of a particular computation (i.e. a SCENARIO of the intended behavior of the system), event diagrams aid in abstracting scripts of modules that are capable of realizing this behavior. For example we plan to explore the abstraction of the scripts of actors for simple procedures for data structures from scenarios of their Intended use. Conversely, they aid in the analysis of an existing system by graphically displaying the relationships among the events occurring in the system for particular cases of behavior. Using the displays available on our time-sharing system, we would like to automate the construction and analysis of event diagrams that have been done by hand in this paper. We would like to investigate the construction of an "eclectic magnifying glass" which provides flexible ways to specify which events and relationships in the history of a computation are to be displayed. Extract: Characterization of Recursion as a Pattern of Passing Messages Thus we see how recursion can be characterized as a pattern of passing messages using event diagrams. The characteristic feature is the build up of a chain of continuation actors each one of which knows only about the next and which eventually replies to the next with the answer. Notice that this characterization of recursion in terms of relations between events is independent of the syntax of the language for scripts which gives rise to the behavior. For example the same characterization would hold for a recursive implementation of factorial in ALGOL. The semantics of ALGOL can be defined using relations among events in a manner similar to the way in which the semantics of PLASMA is defined. The existence of the actors labeled C' and C" in the above diagram and the events in which they are the target are difficult to explain in terms of the above PLASMA script for factorial. In order to explain the origin of these actors and events, we need to explain more of the underlying implementation of PLASMA. Extract: Envelope Level Scripts Envelope Level Scripts Thus far in our PLASMA scripts we have examined information communicated in the messages of envelopes. At this point we would like to introduce the envelope level which allows access to other information in the messengers of actor transmissions. Every messenger always contains (among other things) an actor which serves as the ENVELOPE. In turn every envelope always contains an actor which serves as the MESSAGE. Additionally REQUEST envelopes contain actors called CONTINUATIONS to which replies to the messages should be sent. The reason that it is useful to introduce the envelope level transmitters and receivers into scripts is that otherwise much of the control structure (pattern of passing messages) has to remain implicit in something like an evaluator or a compiler. Envelope receivers and transmitters provide the mechanism for expressing more explicit scripts so that none of the processing or allocation of storage is going on behind the scenes. Envelope receivers and transmitters are analogous to ordinary receivers and transmitters in many respects. They are intended to be used as a notation for writing scripts in which all the computational events and actors are explicitly shown. In this way the structure of simple control structures such as iteration and recursion can be explicitly characterized as patterns of passing messages. PLASMA uses the syntactic convention of using the number of shafts on the transmitter and receive arrows to reflect the level at which the transmission is being referenced; one shaft meaning ordinary message level, and two shafts meaning envelope level. Thus: <= is an (ordinary) message-level-transmitter, and <== is a envelope-level-transmitter. Similarly, => is an (ordinary) message-level-receiver, and ==> is an envelope-level-receiver. Below we use this notation to make the message-passing underlying the implementation of PLASMA more explicit. For example an ordinary message receiver which receives one argument n and replies with the value (n + Dwritten as can be written at the envelope level as follows: (==> (request: [=n] (reply-to: =c)) (c <== (reply: (n + 1)))) |