A Novel Formal Semantics for a Parallel Object-Oriented Language

A Novel Formal Semantics for a Parallel Object-Oriented Language Giovanny Lucero Palma Martin Musicante Silvio R. L. Meira UFPE - Departamento de Informatica PO Box 7851 - 50732-970 Cidade Universitaria - Recife - PE - Brazil e-mail: fg p,mam,[email protected]

ABSTRACT The Parallel Object-Oriented language POOL integrates object-oriented characteristics with synchronous communication among objects. A novel formal description of POOL is given here. The description is written using Mosses' action notation style of formal speci cation. It is then, compared with other formal speci cations of the language. Understandability, extensibility and modularity are the main features of our description of POOL. Keywords:

Formal Semantics, Action Notation, POOL, Parallel Programming, Object-Oriented Programming.

Introduction Object-oriented programming languages are becoming more and more popular in software development. The exibility of the object-oriented paradigm, which allows for the easy re-use of parts of existing systems, together with its adequacy for bottom-up programming techniques, account for this popularity. The formal description of object-oriented programming languages is a major topic of research in itself. There are many successful attempts in this area, such as the operational semantics description of the language Eiffel in [Vis92], in which the static semantics of the language is de ned. Issues concerning the denotational semantics of object-oriented languages are addressed in [Wol88], and a number of results concerning objectoriented type systems can be found in [Pal88] and [PS91]. The parallel object-oriented language POOL has been described using several formalisms, and thus becoming a standard reference for object-oriented languages formal descriptions. In [AR89], two formal descriptions of POOL are given. These descriptions use the structural operational [Plo81] and the denotational semantics [Sch85] formalisms respectively. In [Wal91], the formal semantics of POOL is given by the translation of POOL programs into Milner's -calculus [Mil91]. Despite their nice formal properties, the descriptions of POOL given in [AR89] and [Wal91] are hard to read and understand. A solid mathematical background is needed to read them. Most programmers (and users of the language) do not normally have this background. In this paper we propose a new semantics for POOL, written in the Action Semantics formalism [Mos92]. Action Semantics Descriptions are, in general, much easier to read and understand than denotational or operational ones. Our purpose is to formally describe the language in a way simple enough, in order to make it understandable for most users. This paper is organized as follows: Section 1 introduces the programming language POOL. Section 2 brie y describes of the Action Semantics formalism. The formal description of the language is given in section 3: The section is divided in three parts, in which the abstract syntax, semantic functions and semantic entities are given, respectively. Section 4 compares our formal description with those in [AR89] and [Wal91]. The modularity features of Action Semantics are demonstrated in that section, by extending the language with new (and useful) constructors. This extension can easily be done within the Action Semantics framework, adding just a few  This work was partly supported by CNPq and CAPES (Brazil). This work was included in Proc. of XV Intl. Conf. of the Chilean Computer Science Society, Arica, 1-3 Nov, 1995.

lines to the description. Section 4 also address the problem of introducing these extensions to the de nitions in [AR89] and [Wal91]. In the last section, we conclude that the Action Semantics framework is appropriate for the semantic description of POOL. This is due to the natural understandability of the Action Semantics primitives.

1 The Programming Language POOL In this section we give an overview of POOL, an object-oriented programming language with parallel constructors. In object-oriented programming, a system is described as a collection of objects. An object is an integrated unit of data and procedures, called methods , acting on such data. The data in an object are stored in variables whose contents can be changed by assignment statements. Encapsulation is a fundamental principle of the object-oriented style of programming. It means that the variables of an object are not accessible from others objects: they are strictly private. The only way in which POOL objects interact is by means of message passing. When an object sends a message, it requests that the receiver executes a method. In general, the sender can include some parameters in the message to be passed to a method, which can return an object as result. This result is passed back to the sender of the original message. Despite the terminology of \message passing", most existing object-oriented languages are sequential in nature: only one object is active at a given time. An object is active when it is executing a method in response to an incoming message. In POOL, parallelism is integrated in the object-oriented model by supplying each object with a body : a local independent process, which is started as soon as the object is created. The body of an object executes in parallel with all the other objects in the system. The basic communication mechanism in POOL is synchronous message passing . The sender requests a method execution using an expression of the form:

; . . . ; argn) This expression explicitly indicates the name of the receiver of the message (its destination). A message is composed by a method name, and a number of expressions: the arguments to be handed over to the method. The receiver answers a request by executing a statement of the form: destination

!

(

method arg1

; . . . ; methodm) In order to execute this statement, an object waits until the arrival of a message. The object will respond to messages requesting the execution of a method whose name appears in the ANSWER list. This statement indicates that exactly one message will be answered at a time. Answer statements are useful in body de nitions, to specify the available methods of the object at a given time. In POOL, the actual communication takes place in the form of a rendezvous. Message's sender and receiver synchronize: the parameters are passed to the receiver's requested method, which is then executed. The result is returned back to the sender of the message. Destructive interference of processes acting on the same data is not a problem in POOL, since the encapsulation of data and the sequentiality of the object's body guarantee mutual exclusion. (

ANSWER method1

Another important concept of object-oriented programming is that of a class : a collection of objects with the same behavior. The elements belonging to a class are called instances. In POOL, a new process is created in order to execute each new instance of a class. This process will execute a body statement, which is present in each class de nition. For a more detailed description of the language, the reader can refer to [AR89] or [Ame88].

2 The Action Semantics Formalism Action Semantics [Mos92] is a formal style of semantic de nition developed to provide \tractable" descrip-

tions of programming languages. Action Semantics descriptions resemble denotational semantics [Mos91], in the sense that equations de ning semantic functions are given to state the meaning of each phrase of a language. In Action Semantics, the meaning of each phrase is given in terms of special constructs called actions. Actions possess a very operational avor. They can be performed, yielding to various possible outcomes:    

normal termination (complete ), exceptional termination (escape ), unsuccessful termination (fail ) or non-termination (diverge ).

Action Notation provides one basic action for each of these behaviors. Actions can be combined in order to obtain complex actions. In [Mos92], combinators corresponding to many control patterns are provided. Together with action notation, a Data Notation is used to describe semantic entities. A collection of algebraically de ned data constructors is provided within the data notation, including numbers, characters, strings, sets, tuples, maps, etc. Action Notation possesses ve facets in which each primitive action and action combinator can behave: The Basic Facet deals with pure control ow. For example, the compound action A1 and A2 performs the sub-actions of actions A1 and A2 with arbitrary interleaving. The Functional Facet deals with transient data, which is given to or received by an action. For example, when the basic action give the given natural receives a natural number as transient data, it completes, giving the received natural number as a transient, as well. The compound action A1 then A2 performs the action A1 rst. All transient data produced by A1 is supplied to A2 , which is performed after A1 completes. The Declarative Facet deals with the manipulation of scoped information, represented by associations of tokens to bindable data. For example, the basic action bind \max-length" to 256 completes its performance producing a binding of the token \max-length" to the natural number 256. The Imperative Facet provides storage handling primitives. A storage, in the action notation context, is a mapping from cells to storable data. For example, the action allocate a cell then store 26 in the given cell

allocates a new cell of the storage, and stores a value in it. This action combines features of both the functional and imperative facets. (Vertical bars are used to guide the correct association of actions, as an alternative to parentheses.) The Communicative Facet provides a system of agents, whose task is to perform actions. Agents can communicate using asynchronous message passing. Communication is reliable, in the sense that no message can be lost during transmission; however, there is no bound to the amount of time taken for a message to arrive to its destination buer after transmission. Each agent is created with its own storage. Encapsulation of actions as data is also provided within action notation. This feature gives a simple way to support the description of procedure and function abstractions in programming languages. For example, the performance of the action give abstraction of

allocate a cell then store 26 in the given cell

completes, giving an abstraction as a transient. An abstraction is an item of data which encapsulates an action. Abstractions can be enacted; this operation results in the performance of the encapsulated action. Both transients and bindings can be supplied to the enacted action. Action Semantics descriptions are modular. This feature allows the modi cation of parts of the semantic description without aecting the whole system, as well as the reusability of modules. One practical example of this can be found in [MM94]. For a more detailed description of action notation, refer to [Mos92] or [Wat91] (the former covers all the aspects related with the formal system; the latter does not cover the communicative facet nor the operational semantics of the notation).

3 POOL Action Semantics The formal de nition of POOL is given in this section. The top-level view of the de nition is as follows:

POOL

Abstract Syntax Semantic Functions Semantic Entities

Section 3.1 de nes the abstract syntax of the language. Semantic functions from syntactic phrases to semantic entities are de ned in section 3.2, while the semantic entities used in the formal description are de ned in section 3.3.

3.1 POOL/Abstract Syntax

This section de nes an abstract syntax for the programming language POOL. In Action Semantics, abstract syntax trees are represented by double brackets ([[. . .]]), in a way that resembles their use in denotational semantics. In order to give a complete description of the language, we need to introduce some syntax that is left open in [AR89]: The syntactic de nitions of a program, class and method are given by equations (1) to (3) below.

grammar: (1) (2) (3)

Program = [ \PROGRAM" Class-Def+ \;" Statement ] . Class-Def = [ \CLASS" Class-ID \VAR" Inst-Var-ID* Meth-Def* Statement ] . Meth-Def = [ \METHOD" Meth-ID \(" Temp-Var-ID \)" Expression ] .

Equation (1) de nes the syntax of a POOL program as a sequence of class de nitions followed by a statement. The execution of a program will be initiated by running this statement. Every new object created by the initial statement will trigger new threads of computation, in a truly concurrent way. Each class is composed by a number of instance variable and method declarations, followed by a statement, as de ned by equation (2). Each time a new instance of a class is created (using the expression new C ), it will execute the class statement. Equation (3) shows the abstract syntax for method declarations. They contain a method name, a parameter and an expression. The result of the method will be determined by the evaluation of this expression. As in [AR89], methods taking just one argument are speci ed. The introduction of multiple parameterized methods is a simple task in our framework. We choose to preserve the original setting, in order to facilitate the comparison with the other POOL descriptions in [AR89, Wal91].

In POOL, temporary variables are just method parameters. The addition of other (local-to-methods) temporary variables can be done in a very simple way as well. The abstract syntax of expressions is shown by equation (4): (4)

(5) (6) (7)

Expression = Inst-Var-ID Temp-Var-ID Integer-Constant \true" \false" \nil" \self" [ Expression \!" Meth-ID \(" Expression \)" ] [ Meth-ID \(" Expression \)" ] [ \new" Class-ID ] [ Statement \;" Expression ] [ Expression \" Expression ] Integer-Constant = 2 . Inst-Var-ID = 2 . Temp-Var-ID = 2 .

Instance and temporary variables will evaluate to the value they store. Standard objects like integers and boolean values are present in the language of expressions as well. The token nil represents a reference to no object, while self is used within an object to refer to the object itself. The expression \E1 ! M (E2 )" corresponds to a synchronous request from the performing object to object E1 , which will execute the method M having the result of E2 as its actual parameter. The expression \M (E)" will call a local method M . The value obtained from the evaluation of the parameter E will be passed to the method M . The \new C " directive will trigger a new instance of the class C , returning the newly created object. The sequence of a command and an expression (S;E ) will return the value of the expression E , after the execution of the command S . The operator  is provided to compare two objects. It returns a boolean value. Other arithmetical, logical and relational operations can be added in the same way as  is written. The symbol `2 ' in the right-hand side of the three last rules indicates that this side of the equations will not be lled out at this time. These rules correspond to syntactic tokens of the language. The next equation de nes the abstract syntax for POOL statements: (8)

Statement = [ Inst-Var-ID \:=" Expression ] [ Temp-Var-ID \:=" Expression ] [ \answer" Meth-ID* ] Expression [ Statement \;" Statement ] [ \if" Expression \then" Statement \else" Statement \ " ] [ \while" Expression \do" Statement \od" ] .

The language of statements contains assignments of both instance and temporary variables, indicated by the := operator. The answer statement is in exact correspondence with the one explained in the previous section. The other constructors for statements are straightforward, matching their intuitive meaning in imperative programming languages.

3.2 POOL/Semantic Functions

In this section we de ne a set of semantic equations, in order to state the meaning of each phrase of the language.

The semantics of programs, declarations, expressions, and statements are given by the semantics schemes

run , elaborate , evaluate and execute respectively. 

introduces: run , elaborate , evaluate , execute .

The meaning of a unit [ \PROGRAM" C \;" S ] is an action that, when performed, execute the unit body S , using the bindings produced by the elaboration of the classes declarations in C .  (1)

run :: Program ! action . run [ \PROGRAM" C :Class-Def+ \;" S:Statement ] = lookup global bindings of C before elaborate C hence execute S.

The action lookup global bindings of C de nes dummy indirect bindings of all class names declared in C . These indirect bindings will be \updated" to the nal bindings when performed the next action elaborate C . In this way, all the class names will be known at the time of the elaboration of each class.   (2) (3)

privately introduces: lookup global bindings of . lookup global bindings of :: Class-Def+ ! action . lookup global bindings of C :Class-Def = indirectly bind C to unknown . lookup global bindings of h C1:Class-Def, C2:Class-Def+ i = indirectly bind C1 to unknown and lookup global bindings of C2 .

The meaning of class declarations is de ned by the elaborate scheme below:  (4)

elaborate :: Class-Def+ ! action . elaborate h C1:Class-Def, C2 :Class-Def+ i = elaborate C1 before elaborate C2 .

The action combinator before, used in the elaboration of a sequence of class declarations, behaves in a way that the bindings produced by previous elaborations are passed to subsequent ones. (5)

elaborate [ \CLASS" I :Class-ID \VAR" V :Inst-Var-ID* M :Meth-Def* S:Statement ] = give closure of abstraction of furthermore elaborate V before elaborate M hence execute S then redirect I to the given abstraction .

The elaboration of a CLASS construction produces the nal binding between the class name and an abstraction. This abstraction encapsulates the action to be performed by all the class instances. This action use the bindings of all the instance variables and methods of the class, as well as the bindings for all the class names in the unit. This is done by means of the closure primitive in the above equation. The meaning of instance variables declarations is given by the (overloaded) semantic function elaborate , in the next equations.  (6)

elaborate :: Inst-var-ID* ! action . elaborate h i = complete .

(7)

elaborate h I1 :Inst-var-ID, I2:Inst-var-ID* i = allocate a cell then bind I1 to the given cell and elaborate I2 .

The declaration of one instance variable is elaborated by binding the corresponding identi er to a fresh storage cell. The elaboration order of several instance variables is implementation-dependent; therefore, it is de ned using the interleaving combinator and. The semantics of method declarations is given by the next equations:  (8) (9)

 (10)

elaborate :: Meth-Def* ! action . elaborate h i = complete . elaborate h M1 :Meth-Def, M2 :Meth-Def* i = elaborate M1 and elaborate M2 . elaborate :: Meth-Def ! action . elaborate [ \METHOD" I1 :Meth-ID \(" I2 :Temp-Var-ID \)" E:Expression ] = give closure abstraction of furthermore regive and allocate a cell then store the given value#1 in the given cell#2 and bind I2 to the given cell#2 hence evaluate E then bind I1 to the given abstraction .

The last equation de nes an action binding the method name (I1 ) to an abstraction. This abstraction encapsulates an action, which binds the formal parameter identi er I2 to the actual parameter before the evaluation of the method body. In which follows, the evaluation of POOL expressions is de ned by the evaluate scheme. The next equations de ne actions that give the meaning of expressions. The performance of these actions returns the value denoted by the expression, using the transient facet of Action Notation.  (11) (12) (13)

evaluate :: Expression ! action . evaluate \true" = give true . evaluate \false" = give false . evaluate N :Integer-Constant = give the integer of N .

Equations (11) to (13) use the standard Data Notation [Mos92] for integers and truth values. The function the integer of , which is de ned within the standard Data Notation, receives an Integer-Constant (a syntactic entity) as argument and returns the corresponding integer (a semantic value). (14) (15) (16)

evaluate I :(Inst-Var-ID Temp-Var-ID) = give the entity stored in the cell bound to I . evaluate \self" = give the performing-agent . evaluate \nil" = give the no-object .

The evaluation of an identi er is obtained by accessing the cell bound to it, and returning the value stored in that cell. The evaluation of \self" gives the object (in this case, an action semantics agent) performing the current action1. The evaluation of \nil" returns the semantic entity called no-object, an individual datum which represents no object of the system. This entity is de ned in section 3.3 below. 1 Notice that the function the , in action notation, is used to enhance the readability of the speci cation. It corresponds to the identity function.

evaluate [ E1:Expression \!" M :Meth-ID \(" E2 : Expression \)" ] = evaluate E1 and evaluate E2 then send a message[to the given agent#1][containing msg(M , the given entity#2)] and then receive a message[from the given agent#1] then give contents of the given message .

(17)

The semantics of message passing in POOL is de ned in the above equation. The expressions E1 and E2 are evaluated in order to know the receiver of the message and the actual parameter of the required method respectively. The communication is synchronous: it ends when the receiver sends the result of the method execution. It is worth to notice that this scheme allows to the receiver to send a result before it nish its execution. This feature is present in POOL2 [Ame88], but not in the simpli ed language POOL in [AR89], in which major changes should be done for introducing it. As we will see soon, it is easy to introduce this lighter rendezvous in our description. (18) evaluate [ M :Meth-ID \(" E: Expression \)" ] = evaluate E then enact the application of (the abstraction bound to M ) to the given entity .

Calling a local method is possible in POOL. The result of the whole expression is given by the result of calling the method M with the value of the expression E as its actual parameter. (19) evaluate [ \new" C :Class-ID ] = subordinate an agent then send a message [to the given agent][containing the abstraction bound to C ] and regive . In POOL, the \new" constructor allows for the creation of a new instance of a given class. The semantics

of this constructor is to create a new agent which represents the new instance of the class. After the subordination of the new agent, a message is sent to it, containing the abstraction it will perform. This abstraction represents the body of the class, as de ned above. This style of process creation is usual in action semantics descriptions. (20) evaluate [ E1 :Expression \" E2 :Expression ] = evaluate E1 and evaluate E2 then give (the given entity#1 is the given entity#2) . evaluate [ S:Statement \;" E:Expression ] = execute S then evaluate E .

(21)

Two expressions are \equal" if they evaluate to a reference to the same object. It is worth to notice that any other prede ned operations on numbers and truth values can be de ned in the same way as  The evaluation of an expression preceeded by a statement is obtained by executing the statement (probably with side eects) before the evaluation of the expression. The meaning of statements is de ned by the execute scheme:  (22)

execute :: Statement ! action . execute [ \answer" M :Meth-ID* ] = receive a message[containing msg(a Meth-Id[in set of M ], an entity)] then give fst of contents of the given message and give snd of contents of the given message and give the sender of it then enact the application of the abstraction bound to the given Meth-ID#1 to the given entity#2 and give the given agent#3 then send a message[to the given agent#2][containing the given entity#1] .

The execution of an \answer M " statement executes one of the methods speci ed in the supplied method list. A method is non deterministically chosen from all the messages requesting the execution of a method in M . Each message contains a pair formed by a syntactic token (the method name) and the actual parameter, to be passed to the method. Finally, the result of the method execution is returned back to the sender of the message. The remain constructors are typical of imperative languages. Their semantics is de ned by the next clauses, which are fairly self-explanatory. (23)

(24) (25) (26)

(27)

execute [ I :(Inst-Var-ID Temp-Var-ID) \:=" E:Expression ] = evaluate E then store the given entity in the cell bound to I . execute E:Expression = evaluate E then complete . execute [ S1 :Statement \;" S2 :Statement ] = execute S1 and then execute S2 . execute [ \if" E:Expression \then" S1 :Statement \else" S2 :Statement \ " ] = evaluate E then check (the given object is true) and then execute S1 or check (the given object is false) and then execute S2 . execute [ \while" E:Expression \do" S:Statement \od" ] = unfolding evaluate E then check (the given object is false) or check (the given object is true) and then execute S and then unfold .

An assignment is executed by rst evaluating the expression in the right-hand side of the \:=" symbol. The result of this evaluation is stored in the cell bound to the variable identi er. The execution of an expression proceeds just evaluating it. The result of this evaluation is discarded2 . The execution of a [ S1 \;" S2 ] statement executes the statement S1 and S2 in a sequence. The [ \while" E \do" S \od"] statement executes S iteratively while the expression E evaluates to true.

3.3 POOL/Semantic Entities

The semantic entities used in the formal description of POOL are given here. The sort entity contains all the representable values of the programming language. It is formed by all the objects of the language, plus an individual datum called no-object, which is used to denote nil. The sort object contains three disjoint sub-sorts: agent (used to represent POOL object instances), integers and truth-values. It is necessary to de ne some standard sorts in action semantics descriptions: The sort storable is used to denote the type of values which can be stored on a cell. The sort bindable contains the semantic entities that can be bound to tokens, in the declarative facet of action notation. The sort sendable refers to the kind of values which can be sent within messages. The msg sort is used to construct POOL messages, which are formed by a syntactic token (a method name) and a value. 

introduces: msg , msg , fst , snd , object . no-object : datum .

(1)

2

Remember that the evaluation of expressions can have side eects.

(2) (3) (4) (5) (6)

   (7)

object = agent integer truth-value . entity = object the no-object (disjoint) . storable = entity . bindable = abstraction entity . sendable = msg entity abstraction . msg :: (Meth-ID, object) ! msg . fst :: msg ! Meth-ID . snd :: msg ! object . m = msg (t:Meth-ID, o:object) )  fst m = t  snd m = o .

4 Extensions to the Language The language POOL is de ned as a subset of an actual programming language called POOL2 [Ame88]. Several new features can be easily added to the language, in order to obtain a more realistic description. A few of these changes, like allowing any number of method parameters, can be done in a straightforward way in our semantics, just by adding new cell allocation actions in the equation (10) of section 3.2. The addition of multiple parameters is not so simple in the original semantics of POOL [AR89], in which two dierent de nitions are given (one denotational, and one operational). In these semantics, new syntax is added to de ne parameterized expressions and statements, of the form (e; ) and (e; ), respectively. The rst component (e) is an expression, while  and are functions:  ::= u:e ::= u:s Where e is an expression and s represents a statement. The meaning of the new syntax is de ned in a way that the rst component of the pair is evaluated rst. The result is then applied to the second component of the pair. The resulting expression (or statement) will then be evaluated. In order to add multiple parameterization, the rules in [AR89] should be enriched in order to perform a multiple evaluation and substitution of actual parameters. This would obscure the semantics, since the use of parameterized statements is cumbersome. The introduction of multiple parameters in the -calculus description of POOL [Wal91] is simpler than in the operational or denotational ones, but some auxiliary notation (and a speci c protocol) should be used, in order to model the multiple parameter passing. Other modi cations to the language, quite simple to deal with in the action semantics description, could be cumbersome in the approach of [AR89]. The addition of a `return Exp' statement is an example of this situation. The return statement is a key piece in the design of the language POOL2 [Ame88], an extension of POOL. It permits a \lighter rendesvouz", in which the object who requested a method is released before completion of the method execution. This constructor allows for increasing the inherent parallelism of POOL2 programs. The addition of this statement requires some major changes in the operational semantics of [AR89]. In that description, it is the called process itself who freezes the sender of a message while a method is being executed. After the execution, the server object releases the requesting object. This scheme makes impossible for the method body to release the sender object before the end of the method execution. In our case, the `return Exp' statement can be included in the language by adding the following equation to the execute action semantics scheme: 0 0

0

0

(26) execute [ \return" E:Expression ] =

evaluate E then send a message[to the agent bound to \sender"][containing the given object] .

This action evaluates the expression to be returned as the method result, before sending it to the object which required the service. The identity of this object is bound to a pre-de ned identi er \sender". The only other equations to be modi ed are rewritten below. Equation (10) in section 3.2, in which the bindings for the pre-de ned identi er are de ned, should be replaced by: (10) elaborate [ \METHOD" I1 :Meth-ID \(" I2 :Temp-Var-ID \)" E:Expression ] =

give closure abstraction of furthermore regive and allocate a cell then store the given value#1 in the given cell#3 and bind I2 to the given cell#3 and bind \sender" to the given agent#2 hence evaluate E then bind I1 to the given abstraction .

Equation (22), which de nes the answer statement, should be simpli ed, since it will not send the result back to the sender anymore: (22) execute [ \answer" M :Meth-ID* ] =

receive a message[containing msg(a Meth-Id[in set of M ], an object)] then give fst of contents of the given message and give snd of contents of the given message and give the sender of it then enact the application of the abstraction bound to the given Meth-ID#1 to h the given object#2, the given agent#3 i .

The addition of a return statement in the -calculus description in POOL [Wal91] is as simple as in our action semantics description

Conclusions We described the formal Action Semantics of the parallel object-oriented language POOL. Action Semantics proved to be suitable for the description, yielding a very simple and well-structured formal de nition. This is partly because of the standard data notation used in Action Semantics, in which all the constructions (such as numbers, truth-values, sets, tuples, etc) corresponds to concepts that are known to programers. The basic actions and combinators present in Action Notation are familiar to programmers, as well. We illustrated the modularity and extensibility properties of action semantics de nitions, by extending the semantic description with a new constructor. We shown that a similar extension to the original description of POOL would be not so simple. Our description is about three pages of raw equations. It is about twice the size of the other three descriptions in [AR89, Wal91]. But, while the other semantics of POOL were given in order to exploit their mathematical properties, our motivation was dierent: we intended to give a completely formal de nition, enhancing the understandability of the description. We can assert, from the results (shown here), that we succeeded in doing so.

References [Ame88] P.H.M. America. Issues in the design of a parallel object-oriented language. ESPRIT Project 415 Document 452, Philips Research Laboratories, Eindhoven, 1988. [AR89] P.H.M. America and J.J.M.M Rutten. A Parallel Object-Oriented Language: Design and Semantic Foundations, chapter 1 of [dB89]. John Wiley & Sons Ltd, 1989. [dB89] J.W. de Bakker, editor. Languages for Parallel Arquitechtures: Design, Semantics, Implementation Models. Wiley Series in Parallel Computing. John Wiley & Sons Ltd, 1989. [Mil91] Robin Milner. The polyadic -calculus: A tutorial. LFCS Report Series ECS-LFCS-91-180, Laboratory for Foundations of Computer Science - University of Edinburgh, 1991. [MM94] Peter D. Mosses and Martin A. Musicante. An action semantics for ML concurrency primitives. Em Maurice Naftalin, Tim Denvir, and Miquel Bertran, editors, Proc. FME'94 (Formal Methods Europe, Symposium on Industrial Bene ts of Formal Methods), number 873 in Lecture Notes in Computer Science, Barcelona, Spain, October 1994. FME, Springer-Verlag. [Mos91] Peter D. Mosses. A practical introduction to denotational semantics. Em Ehrich J. Neuhold and Manfred Paul, editors, Formal Description of Programming Concepts, IFIP State-of-the-Art Report, pages 1{49. Springer-Verlag, 1991. [Mos92] Peter D. Mosses. Action Semantics. Number 26 in Cambridge Tracts in Theoretical Computer Science. Cambridge University Press, 1992. [Pal88] Jens Palsberg. An Action Semantics for Inheritance. M.Sc. dissertation, Aarhus University, 1988. [Plo81] Gordon Plotkin. A structural approach to operational semantics. Lecture Notes DAIMI FN-19, Aarhus University, Computer Science Department, 1981. Now available only from University of Edinburgh. [PS91] Jens Palsberg and Michael I. Schwartbach. Object-oriented type inference. Em Proc. ACM Conf. on Object-Oriented Programming: Systems, Languages and Applications, 1991. [Sch85] David A. Schmidt. Denotational Semantics: A Methodology for Language Development. Allyn & Bacon, 1985. [Vis92] Eelco Visser. Syntax and static semantics of eiel: A case study in algebraic speci cation techniques. Internal report, Programming Research Group, Dept. of Mathematics and Computer Science, University of Amsterdam, 1992. [Wal91] David Walker. -calculus semantics of object-oriented programming languages. Em Proc. Conference on Theoretical Aspects of Computer Software. Tohoku University - Japan, September 1991. [Wat91] David A. Watt. Programming Language Syntax and Semantics. Prentice-Hall, 1991. [Wol88] M. Wolczko. Semantics of Object-Oriented Languages. PhD thesis, University of Manchester, 1988.