The ModulaTor

The ModulaTor
Erlangen's First Independent Modula_2 Journal! Nr. 1, Feb-1994 
______________________________________________________________


Modula-2O 

An object oriented extension of Modula-2 

Dedicated to Professor N. Wirth on the occasion of his 60th birthday 

Markus Klingspor and Juergen Wolff von Gudenberg 

Institut fuer Informatik 

Universit~at Wuerzburg 

D-97074 Wuerzburg 

November 1993 [ed. note: revised in Feb-1994; submitted to The ModulaTor in 
03-Feb-1994] 

Abstract: In this paper we summarize some ideas which currently are discussed 
concerning the extension of the ISO-Modula-2 Standard [iso] and combine 
these with our opinion how a type safe object oriented modular language with 
separate compilation should be defined. One of the main design principles of 
Modula-2O was to generate a genuine object oriented language and maintain 
upward compatibility to Modula-2 by introducing the extensions orthogonally. 
Although many of the key object oriented features can be simulated by 
procedural components of records with slight extensions [wm2oop], we propose 
the introduction of class types as the main building block which enables us to 
define dynamic entities, realize late binding and polymorphism, and allows for 
multiple inheritance and generic data types. Many of the newly introduced 
features are well known from other object oriented languages [cpp, eiffel, 
oberon2, modula3] but some ideas are new like the solution of constrained 
genericity, the covariant type-checked refinement of methods or the means of 
handling VAR parameters together with polymorphism. 

(We like to thank the members of the Modula-2 Interessen Gemeinschaft for fruitful comments.) 

 

Class Types 

The key features of object oriented programming like autonomous dynamic 
objects, (multiple) inheritance, late binding of methods, polymorphism and 
genericity are all introduced in connection with classes. Classes -- in other 
languages called objects -- contain attributes which may be modified by class 
type specific methods. Attributes and methods are subsumed under the name 
features in this paper. 

Although class types and modules seem to have many things in common, class 
types should not be denoted as modules as e.g. in Modula-2/90 [odersky]. The 
main reason for this is backward compatibility. Either every module is a class 
type which would cause problems for code written in Modula-2, or no module 
should be considered as a class type. 

On the other hand record types with their data and procedural components do 
not support late binding and object autonomy and therefore are not suitable to 
represent class types. 

Therefore we introduce class types as an extension of record types. 

 

Type Definition 

The complete definition of a class type is separated into two parts, the interface 
or type definition in the definition module and the associated method bodys in 
the implementation module. 

The new keyword CLASS commences the type description and in an 
implementation module opens, for the implementation of the methods of the 
class type, a new scope where all its features are directly visible . This scope 
also contains an initialization and a finalization part like a local module. Since all 
features of a class type are thus contained in two contiguous parts the 
readability of the code is high in contrast to Oberon-2 or C++ which heavily rely 
on a browser. 

DEFINITION MODULE Classes;

TYPE TClassExample = CLASS
                       x: TX;
                       PROCEDURE X(x: TX);
                       y: READONLY TY;
                       PROCEDURE Y(y: TY);
                     PROTECTED
                       z: TZ;
                       i: READONLY INTEGER;
                       PROCEDURE Z(z: TZ);
                     PUBLIC
                       j: INTEGER;
                     END;
END Classes.

IMPLEMENTATION MODULE Classes;

CLASS TClassExample;
  VAR l,m: INTEGER;

  PROCEDURE X(x: TX);
  BEGIN
    ...
  END X;
  PROCEDURE PrivateMethod;
  BEGIN
  END PrivateMethod;
  PROCEDURE Y(y: TY);
  BEGIN
    ...
  END Y;
  PROCEDURE Z(z: TZ);
  BEGIN
    ...
  END Z;
BEGIN
  x := 42;
FINALLY
  x := 0;
END TClassExample;

END Classes.
 

All features listed in the class type description in the definition module are 
exported which resembles the export of records in Modula-2. Their access from 
outside the module can, however, be restricted by the new keywords 
READONLY or PROTECTED (see Visibility). 

Additional rules are not needed. So, the unit of visibility is the module of the 
class type definition (where every statement may access all features of the 
class). This is the same approach as taken in Oberon-2 [oberon2]. 

Classes, i.e. variables of class type, are dynamic data structures and implicitly 
hold a pointer to the actual instance of the structure. Consequently they are 
created by a call of the standard procedure NEW which obtains an additional 
optional parameter denoting the actual class type of the object to be created. 

Class features are accessed like record fields in Modula-2, no explicit 
dereference is needed. A reference to the calling object of a method is passed 
as an implicit first parameter. Inside the method body this parameter is called 
SELF. 

So classes are implicit pointers. Since sometimes it is desirable to have classes 
as static entities, we introduce an expanded class type by the definition 
EXPANSION OF < class type name >. 

This mimics the declaration of dynamic types in Modula-2. At the first sight it 
might have been more natural to introduce dynamic classes as pointers to the 
by default expanded class types, but that leads to many inconsistencies when 
adding concepts like constrained genericity and redefinition of methods. 

The following declares an expanded class type: 

...
TYPE TClassExample = CLASS
                       ...
                     END;
     TEClassExample = EXPANSION OF TClassExample;

VAR tec: TEClassExample;
    tec2: EXPANSION OF TClassExample;
 

The address of a value of expanded class type can be assigned to a variable of 
dynamic class type. An assignment of the address of a value of expanded class 
type to a VAR parameter of class type is not allowed because there exists no 
variable which actually holds the address. A class can be assigned to a variable 
of expanded class type by dereferencing it. The resulting expanded class type is 
checked to be identical to that of the variable. The explicit notation of the 
dereference was chosen to indicate an assignment to an expanded type. 
Although it is possible to declare pointers to expanded class types, there is not 
much use for it and the resulting type is not compatible to the corresponding 
class type. 

The Introduction of expanded class types leads to an aliasing problem. If inside 
a method of the class type the value of self is returned, it may well point to an 
location in the stack. To avoid this, the possibility to expand a class type may be 
restricted by declaring it as DYNAMIC. Also access to the self value is only 
possible for dynamic class types. 

 

Class Type Variables 

Declaration 

Variables of class type are declared like any other Modula-2 variables. Since 
classes are dynamic structures they must be created before their features can 
be accessed. For dynamic class types the initialization or finalization part is 
executed upon creation and deletion. For each declared variable of expanded 
class type, the initialization and finalization part -- if present -- is executed before 
and after the corresponding parts of the surrounding scope. The surrounding 
scope for global variables is the module in which they are defined. For local 
variables, the initialization and finalization part are executed as a prologue and 
epilogue to the procedure body. 

Creation and Memory Management 

Classes are created by a call of the standard procedure NEW, which has one 
optional parameter denoting the class type of the object to be created. They are 
deleted by a call to the standard procedure DISPOSE. 

MODULE Create;

TYPE TCreate = CLASS
                 x: INTEGER;
               END;
...
VAR ec: EXPANSION OF TCreate;
    c: TCreate;
BEGIN
  (* Here ec is already initialized *)
  NEW(c,TCreate);
END Create.
 

 

Inheritance 

Class types can inherit features from an ancestor type, define additional new 
features and they can redefine inherited features to adjust them to new tasks. In 
this sense, a class type can be a specialization of its ancestor. 

 

Encapsulation and Inheritance 

The encapsulation of data and code is solved correspondingly to the framework 
of Modula-2. Everything listed in the definition module is exported and directly 
visible in an importing module and can be inherited. The access, however, may 
be restricted to conform to the stricter conventions in object oriented 
programming. 

The keyword PUBLIC opens the public section of a class type, this 
characterizes the default case, i.e. direct visibility, read and write access. 

Features declared inside the PROTECTED section of a class type can only be 
accessed outside the module by heirs or descendants (see below). 

The modifier READONLY allows only read access for attributes. It may appear 
in any section. In the protected section of a class type it restricts access for heirs 
of the class type. 

Note: The combination of READONLY and PROTECTED is not considered to 
be important, therefore it is forbidden. 

Private attributes which are not inherited are not allowed. The overhead of 
dragging these attributes as invisible anonymous data fields through the whole 
class type hierarchy which is necessary, if they are accessed -- directly or 
indirectly -- by a public method, seems too large. The problem of completely 
disregarding information from the ancestor should better be solved by a 
redesign of the class type structure, the introduction of a common (abstract) 
ancestor class type, e.g. 

Everything contained in the implementation module like the code of methods is 
encapsulated. It is also possible to define new (private) methods -- which are 
statically bound, whereas the definition of additional attributes is forbidden. 

 

Abstract Class Types 

An abstract class type, specified by the keyword ABSTRACT, only describes an 
interface for some of its methods, no entities of an abstract class type may be 
created. Abstract methods have no implementation in the current class. If an 
abstract class type only contains abstract methods, it does not need to have an 
implementation part at all. 

TYPE TAbstract = ABSTRACT CLASS
                   ABSTRACT PROCEDURE x;
                 END;
 

The concept of abstract classes in the current version of Modula-2O is much 
weaker than in Eiffel [eiffel], because it is not possible to define invariants etc. 
which are inherited. 

 

Single Inheritance 

A class type may inherit features from another class type called its ancestor 
type. In a class type definition, an INHERIT clause indicates that the new class 
type inherits all features from the specified ancestor class type. 

...
TYPE TParent = CLASS
                 x,y: INTEGER;
                 PROCEDURE test;
               END;
     TChild = CLASS
                INHERIT TParent;
                z: INTEGER;
                REDEFINE PROCEDURE test;
                PROCEDURE Test;
              END;
...
 

The features of the ancestor type are directly visible in the descendant class. 
Methods may be redefined and attribute access restricted, however. The 
redefinition of methods has to appear in the definition module and must not be 
an abstract definition. The user of a class who only sees the definition module 
should know the place of definition of a method. The keyword REDEFINE must 
appear before every redefined method to avoid the unintended declaration of 
new methods. The heir of a class should see all attributes of its ancestor, since 
Modula-2O does not support anonymous attributes. 

 

Redefinition of methods 

A class type may redefine parameter and result types of inherited methods. The 
only restriction is that any redefined parameter type must be a descendant of 
the original type and may not be an expanded class type. 

...
TYPE TX = CLASS
          END;
     TY = CLASS
            INHERIT TX;
          END;
     TParent = CLASS
                 x,y: INTEGER;
                 PROCEDURE test(t: TX): TX;
               END;
     TChild = CLASS
                INHERIT TParent;
                REDEFINE PROCEDURE test(t: TY): TY;
              END;
...
 

Redefinition of method parameter types together with late binding (see Binding) 
leads to a hole in the type system, as was exposed by Cook [cook] and is shown 
in the following example: 

...
TYPE TX = CLASS
            PROCEDURE test(t: TX);
          END;
     TY = CLASS
            INHERIT TX;
            REDEFINE PROCEDURE test(t: TY);
          END;
...
VAR x: TX;
    y: TY;
BEGIN
  ...
  x := y;
  x.test(x);
 

The call of x.test(x) is really a call of the implementation of the method test in 
class type TY inside which we now have an entity of type TX assigned to a 
parameter of type TY which is a violation of type compatibility rules (see 
Binding). 

The problem is solved by an additional type check for every redefined 
parameter. This code is only generated for methods that actually have those 
parameters which keeps the introduced overhead relatively small. 

The redefinition of method result types leads to no problem. If a result type is 
redefined, the type of the RETURN statement is checked at compile time inside 
the method. A direct call to the method is also checked correctly at compile time. 
If the method is called indirectly via the interface of the original inherited method, 
it returns a descendant type which is perfectly valid in the sense of 
polymorphism. 

 

Multiple Inheritance 

The main advantage of multiple inheritance is, that it is possible to introduce 
concepts at any level of a class type hierarchy without either programming them 
from scratch or dragging them through the whole hierarchy. Of course, multiple 
inheritance introduces some new problems to deal with. One problem are name 
clashes, because it is possible that several features which have the same name 
can be inherited from different base classes. Name clashes are resolvable by 
qualified access. Qualified access is denoted syntactically by appending the 
appropriate type in square brackets. Qualification may be repeated. 

On the other hand any implementation of multiple inheritance leads to an 
overhead in either time or space. But there exist sophisticated implementations 
of multiple inheritance [minheritance] which keep this overhead relatively small 
so that compared to the gain of flexibility this is nothing to worry about. Objected 
oriented programming was introduced merely to deal with program complexity 
and not for efficiency reasons. 

The following gives an example of multiple inheritance: 

MODULE Clashes;

TYPE TA = CLASS
            a: INTEGER;
          END;
     TB = CLASS
            a: INTEGER;
          END;
     TC = CLASS
            INHERIT TA, TB;
          END;

VAR c: TC;
BEGIN
  c[TA].a := 11;
  c[tB].a := 42;
  (* an access to c.a is not unique and therefore unresolva
ble. *)
END Clashes.
 

 

Ancestor Calls 

If the functionality of an inherited method shall only be extended and not 
completely modified it is necessary to access the inherited method. This is not 
achievable through a type cast because the method binding is dynamic (see 
Binding). The call of an inherited method is written by qualification: 

  AncestorTypeName.MethodName(...
 

The method called is the last (re)definition of the corresponding method 
MethodName in the hierarchy of class type ancestors of the class type 
AncestorTypeName. Thus it is not only possible to call the ancestor method 
which corresponds to the method inside which the statement occurs, but any 
ancestor method that is visible in the current scope. If a method was defined 
private -- i.e. inside the implementation module, then it is not inherited and can 
not be redefined. 

 

Type Compatibility (Polymorphism) 

In object oriented programming it is possible to assign entities of class types to 
variables of their -- direct or indirect -- ancestor types. We allow this only for 
dynamic classes. Assignments of the form 

  X := Y;
 

are only possible if the type of Y is compatible to the type of X. An expanded 
class type is only compatible to itself, whereas a dynamic class type is 
compatible to all its ancestors. Otherwise a value would only partially be 
assignable to a static variable of its ancestor type which means that a projection 
would take place and dynamic binding of methods (see Binding) would be 
replaced by static binding. Our experiences have shown that projection is 
unnecessary and only leads to problems and irritations. 

 

Dynamic binding 

Methods redefined in descendant types are dynamically bound to the actual 
type at runtime. 

The following gives an example: 

TYPE TX = CLASS
            PROCEDURE test;
          END;
     TY = CLASS
            INHERIT TX;
            REDEFINE PROCEDURE test;
          END;

VAR x: TX;
    y: TY;
BEGIN
  x.test;
  x := y;
  x.test;
 

The first call to x.test really calls the implementation of the method test in class 
TX whereas the second call to x.test really calls the implementation of the 
method test in class TY, as the actual type of x after the assignment x := y is TY. 

 

VAR Parameters (The Swap Problem) 

Polymorphism together with the use of VAR parameters causes a severe 
problem which is not solved sufficiently in commonly used object oriented 
languages [cpp, eiffel, oberon2]. 

We consider the following example: 

MODULE SwapCars;

TYPE TCar = CLASS
              ...
            END;
     TVolkswagen = CLASS
                     INHERIT TCar;
                     ...
                   END;
     TBMW = CLASS
              INHERIT TCar;
              ...
            END;

(* Mercedeses are too expensive to be considered here *)

PROCEDURE SwapCar(VAR a,b: TCar);
VAR tmp: TCar;
BEGIN
  tmp := a; a := b; b := tmp;
END SwapCar;

VAR b: TBMW;
    v: TVolkswagen;
BEGIN
  NEW(b,TBMW);
  NEW(v,TVolkswagen);
  SwapCar(v,b);
END SwapCars.
 

This will lead to a type error which is not detectable at compile time. To be able 
to detect the error at runtime, VAR parameters are treated differently if they are 
of dynamic class type -- the problem arises only for dynamic class types 
because in the case of expanded class types the polymorphic assignment is not 
allowed. Before execution of the body of the procedure or method the type 
signature of every VAR parameter of dynamic class type is saved in a hidden 
local variable and on every assignment to that parameter, the signature of the 
value to be assigned is checked to be compatible with the saved signature. 
Thus for every VAR parameter an additional parameter must be passed, which 
denotes the static signature of the passed variable. If the signatures do not 
match a runtime error will occur. 

 

Genericity 

Genericity is not only a special case of inheritance and polymorphism as it is 
often said. Genericity can roughly be simulated through polymorphism [eiffel], 
but then type consistency is no longer provable at compile time. As Modula-2 is 
a strongly statically typed language, it conforms more to the nature of the 
language itself to introduce genericity on a syntactic basis as to rely on the 
programmer to use runtime type checking to achieve this goal. 

 

Unconstrained Genericity 

Since classes are complex entities, which have something of a life of their own, 
it should not become common style to cast around classes between different 
types. To be more specific, it should not be necessary to use type casts to build 
generic structures. This is to be understood in the sense of reusability. If a 
programmer has written code for a doubly linked list, he would like to use this 
code again and again for different purposes without the need to rewrite it from 
scratch every time. This goal can be achieved through generic or parameterized 
class types. A class type is called generic or parameterized, if it contains entities 
of unspecified types. The following shows an example of a generic class: 

MODULE Generics;

TYPE TGenericStack = CLASS [T]
                       PROCEDURE Push(element: T);
                       PROCEDURE Pop():T;
                     END;
     TInteger = CLASS
                  value: INTEGER;
                END;

CLASS TGenericStack;
...

END TGenericStack;

VAR TIntStack: TGenericStack[TInteger];
    i: EXPANSION OF TInteger;
BEGIN
  i.value := 17;
  TIntStack.Push(i);
  ...

END Generics.
 

 

Constrained Genericity 

Constrained genericity allows a generic class type to access features of some 
basic class type for its generic parameters. Any parameter, for which an actual 
type is instantiated must be a descendant of the formal constraint type. 

TYPE TSortable = ABSTRACT CLASS
  ABSTRACT PROCEDURE IsLessThan(elem: TSortable): BOOLEAN;
  ABSTRACT PROCEDURE IsGreaterEqual(elem: TSortable): BOOLEAN;
     END;
  TSortedListElem = CLASS [T: Sortable];
    data: T;
    next: TSortedListElem;
    PROCEDURE Insert(member: T);
  END;
  TSortableStudent = CLASS
    INHERIT TSortable;
    REDEFINE PROCEDURE IsLessThan(elem: TSortableStudent): BOOLEAN;
    REDEFINE PROCEDURE IsGreaterEqual(elem: TSortableStudent): BOOLEAN;
  END;

VAR sortedStudentList: TSortedListElem[TSortableStudent];
 

A problem arises with the creation of attributes of the formal generic type. 
During compilation it can not be determined how much storage is needed and 
which initialization code is to be executed for the actual generic parameter 
which is not known yet. The problem can be solved by indirecting this calls 
through a type parameter table which contains the needed information for every 
generic parameter and is set up for every instance of the generic type. 

 

Overloading 

It is possible to overload procedures and all predefined operators. Syntactically 
operators and functions are treated differently. 

For example to overload the "+" operator we write: 

PROCEDURE UniqueName OPERATOR "+" (arg1, arg2: type): type;

 

To overload a procedure (e.g. INC) we write: 

PROCEDURE UniqueName OVERLOAD INC (VAR arg1: type);
 

The overloaded name must already be visible and the parameter type signature 
must be unique in this scope. 

It is also possible to overload a method or to define an overloaded operator as a 
method. In this case a binary operator may only have one parameter, as the 
other one is determined by the binding class. 

The UniqueName needs to be unique inside its scope and makes it possible to 
import a single overloaded operator or procedure, additionally an expression 
can be transformed into a unique form for debugging purposes. Also the 
corresponding procedures can be called like normal procedures by their 
UniqueName. Operators are of course infix and their predefined priority remains 
unchanged. 

To import operators or overloaded procedures from another module there are 
several possibilities: 

FROM X IMPORT OPERATOR "+"; imports all operators "+" defined in X.
FROM X IMPORT UniqueName;   imports one operator or overload by its name.
FROM X IMPORT OVERLOAD INC; imports all overloads of INC from X.
FROM X IMPORT OPERATOR;     imports all operators;
FROM X IMPORT OVERLOAD;     imports all overloaded procedures;
 

In the case of an unnamed import like IMPORT OPERATOR, the unique names 
are not imported to avoid naming conflicts. Also we did not include an IMPORT 
ALL like Modula-2 SC [modula2sc] for just the same reason. Naming or 
signature conflicts can also be resolved by qualification with the module name. If 
operators or overloaded procedures are imported via their unique name, their 
overloaded name or operator symbol is hidden and they must be called like 
ordinary procedures. 

TYPE tOperator = CLASS
                   PROCEDURE Test OPERATOR "+" (s: INTEGER);
                 END;
(* Implicit SELF Parameter! , Imported with CLASS *)

PROCEDURE MatrixAdd OPERATOR "+" (a,b: MATRIX): MATRIX;
PROCEDURE IntegerSwap OVERLOAD Swap(VAR i,j: INTEGER);

FROM x IMPORT MatrixAdd;
FROM x IMPORT OPERATOR "+";
FROM x IMPORT Swap;
FROM x IMPORT OVERLOAD Swap;
FROM x IMPORT OPERATOR;
 

 

Type Information 

Modula-2O supports concepts to determine the runtime type of a class. The 
procedure TYPEOF accepts one parameter which can be an arbitrary variable. 
If the compile-time type of the variable is a dynamic class type, its actual runtime 
type is returned. In all other cases the result is the compile-time type. The 
results of two calls to TYPEOF are comparable. The following shall serve as an 
example: 

TYPE TA = CLASS
          END;
     TB = CLASS
            INHERIT TA;
          END;
     TC = CLASS
          END;
VAR a: TA;
    b: TB;
BEGIN
  NEW(a,TA);
  NEW(n,TB);

  IF TYPEOF(a)=TA THEN ... (* TRUE *)
  IF TYPEOF(a)<=TA THEN ... (* TRUE *)
  IF TYPEOF(a)>=TA THEN ... (* TRUE *)
  IF TYPEOF(a)<=TYPEOF(b) THEN ... (* TRUE *)
  IF TYPEOF(a)=TYPEOF(b) THEN ... (* FALSE *)
  IF TYPEOF(b)>=TYPEOF(a) THEN ... (* TRUE *)

  a := b;
  IF TYPEOF(a)<=TA THEN ... (* FALSE *)
  IF TYPEOF(a)>=TA THEN ... (* TRUE *)
  IF TYPEOF(a)=TA THEN ... (* FALSE *)
  IF TYPEOF(a)=TB THEN ... (* TRUE *)

  IF TYPEOF(a)<=TC THEN ... (* FALSE *)
  IF TYPEOF(a)>=TC THEN ... (* FALSE *)
 

If TYPEOF(x)<=TYPEOF(y) = TRUE then y is assignable to x. 

It is also possible to use TYPEOF in a type-case statement: 

...
  TYPECASE TYPEOF(a) OF
    TA: ...
  | TB:
  END;
 

In contrast to the usual case statement in Modula-2 the alternatives need 
neither be matched exactly nor need they be mutually exclusive. The first 
alternative which conforms to TYPEOF(a) is chosen. 

Note: Inside the chosen alternative, the type is accessible as the type of the 
alternatives label. This leads to an aliasing problem if the parameter of TYPEOF 
is an arbitrary designator. As this problem is not solvable easiliy, we decided to 
remove automatic casting. 

Inside the alternative the type is not automatically casted to avoid aliasing 
problems. 

It is further possible to enforce type checking on assignments and parameter 
passing in Modula-2O. This is implemented by placing the type guard against 
which the actual runtime type of a variable should be checked in square 
brackets after the variable. The assignment in the following example would be a 
compile time error without the added type guard and a runtime error if the 
runtime type of a is not compatible with TB. 

...
  b := a[TB];
 

 

Summary 

We have shown that our approach presents some powerful new concepts 
(Genericity, Varpar, etc.) which are easy to use and can be implemented quite 
efficiently as a test implementation of a compiler for a subset [diplom] has 
demonstrated. 

 

Bibliography 

[wm2oop] J. Bergin, S. Greenfield: What Does Modula-2 Need to Fully Support 
Object Oriented Programming? SIGPLAN Notices, Vol. 23, No. 3, March 1988. 

[modula3] L. Cardelli, et al.: Modula-3 Report. SRC Research Report 31, DEC 
1988. 

[cook] W.R. Cook: A Proposal for Making Eiffel Type-safe. The Computer 
Journal, Vol. 32, No. 4, 1989. 

[chorn] C. Horn: Conformance, Genericity, Inheritance and Enhancement. 
Bezivin et. al. eds., ECOOP 87, LNCS 276, pp. 223-233. 

[minheritance] Shih-Kun Huang, Deng-Jyi Chen: Efficient algorithms for method 
dispatch in object-oriented programming. Journal of Object Oriented 
Programming, Vol. 5, No. 5, September 1992. 

[iso] Document ISO/IEC JTC1/SC22/WG13 D181. BSI, Leicester University, 
1992. 

[diplom] M. Klingspor: Implementierung objektorientierter Konzepte in einen 
Modula-2 ~Ubersetzer. Diplomarbeit, Universit~at Wuerzburg, 1992. 

[modula2sc] C.F. Korn, S. Gutzwiller, S. K~onig: Modula-SC a Precompiler to 
Modula-2. In Contributions to Computer Arithmetic and Self-Validating 
numerical methods, J.C. Baltzer AG, 1990. 

[eiffel] B. Meyer: Object-oriented Software Construction. Prentice Hall, 1988. 

[oberon2] H. M~ossenb~ock: Objektorientierte Programmierung in Oberon-2. 
Springer Verlag, 1992. 

[odersky] M. Odersky: Extending Modula-2 for Object-oriented Programming. 
First international Modula-2 conference, 1989. 

[cpp] B. Stroustrup: The C++ Programming Language, Second Edition. Addison 
Wesley, 1991. 

[objpas] L. Tesler: Object Pascal Report. Apple Computer 1985. 

[pim3] N. Wirth: Programming in Modula-2, 3rd Edition. Springer Verlag, 1985. 

 

The ModulaTor Forum 

From: sanders@inf.ethz.ch (Beverly Sanders)
Newsgroups: comp.lang.eiffel,comp.compilers,comp.lang.modula2,comp.lang
.oberon
Subject: Final Program: Prog. Langs and System Architectures (March 94,
 Zurich)
Keywords: conference
Date: Mon, 31 Jan 1994 12:14:44 GMT
Sender: compilers-sender@chico.iecc.com
Organization: Dept. Informatik, ETH, Zurich, CH
Approved: compilers@chico.iecc.com

A formatted postscript version of this announcement is
available via ftp from neptune@inf.ethz.ch in file ~ /ftp/pub/PLSA.ps

+-------------------------------------------------------+
|                       PLSA'94                         |
|                                                       |
|              International Conference                 |
|   on Programming Languages and System Architectures   |
|                                                       |
|               With a Special Session                  |
|    in Honor of Niklaus Wirth on his 60th Birthday     |
|                                                       |
|                  March 2-4, 1994                      |
|                    ETH Zuerich                        |
|                    Switzerland                        |
+-------------------------------------------------------+

CONFERENCE PROGRAM 

WEDNESDAY, MARCH 2 

Topics: Optimization, Concurrency 

Session 1 Chair: Juerg Gutknecht, ETH Zuerich, Switzerland 

9:15 - 9:30 Opening Address Carl August Zehnder and Juerg Gutknecht 

9:30 - 10:30 Interconnecting Computers: Architecture, Technology, and 
Economics Butler W. Lampson (DEC SRC, Palo Alto, USA) 

Session 2 Chair: Martin Reiser, IBM Research Zuerich, Switzerland 

11:00 - 11:30 On Computing Power Jean E. Vuillemin (DEC Paris Research 
Laboratory, France) 

11:30 - 12:00 Increasing Memory Bandwidth for Vector Computations Sally A. 
McKee, Steven A. Moyer, William A. Wulf, Charles Hitchcock (University of 
Virginia and Dartmouth College, USA) 

Session 3 Chair: Susan Graham, University of California, Berkeley, USA 

14:00 - 14:30 The Advantages of Machine-Dependent Global Optimization 
Manuel E. Benitez, Jack W. Davidson (University of Virginia, USA) 

14:30 - 15:00 Dependence-Conscious Global Register Allocation Wolfgang 
Ambrosch, M. Anton Ertl, Felix Beer, Andreas Krall (Technical University of 
Vienna, Austria) 

15:00 - 15:30 Type Test Elimination using Typeflow Analysis Diane Corney, 
John Gough (Queensland University of Technology, Brisbane, Australia) 

Session 4 Chair: Beverly A. Sanders, ETH Zuerich, Switzerland 

16:00 - 16:30 Where Concurrent Processes Originate Stanislaw Chrobot 
(Kuweit University) 

16:30 - 17:00 High-Level Abstractions for Efficient Concurrent Systems Suresh 
Jagannathan, James Philbin (NEC Research, Princeton, USA) 

THURSDAY, MARCH 3 

Topics: Programming Language Design, Modular Programming 

Session 1 Chair: Butler W. Lampson, DEC SRC, Palo Alto, USA 

9:00 - 10:00 Languages and Interactive Software Development Susan Graham 
(University of California, Berkeley, USA) 

10:00 - 10:30 Language and Architecture Paradigms as Object Classes 
Diomidis Spinellis, Sophia Drossopoulou, Susan Eisenbach (Imperial College 
London, United Kingdom) 

Session 2 Chair: Gustav Pomberger, University of Linz, Austria 

11:00 - 11:30 Engineering a Programming Language: The Type and Class 
System of Sather Clemens A. Szyperski, Stephen Omohundro, Stephan Murer 
(ICSI Berkeley, USA) 

11:30 - 12:00 OPAL: Design and Implementation of an Algebraic Programming 
Language Klaus Didrich, Andreas Fett, Carola Gerke, Wolfgang Grieskamp, 
Peter Pepper (Technical University of Berlin, Germany) 

Session 3 Chair: Edsger W. Dijkstra, University of Texas, Austin, USA 

14:00 - 15:00 Mechanized Support for Stepwise Refinement Jan L. A. van de 
Snepscheut (Caltech, USA) 

15:00 - 15:30 Architectural Issues in Spreadsheet Languages Alan G. Yoder, 
David L. Cohn (University of Notre Dame, USA) 

Session 4 Chair: Peter Schulthess, University of Ulm, Germany 

16:00 - 16:30 Technological Steps toward a Software Component Industry 
Michael Franz (ETH Zuerich, Switzerland) 

16:30 - 17:00 Distributed High-Level Module Binding for Flexible Encapsulation 
and Fast Inter-Modular Optimization Christian S. Collberg (University of 
Auckland, New Zealand) 

19:00 Conference Banquet Hotel Zuerich, Neumuehlequai 42 

FRIDAY, MARCH 4 

Topic: Oberon 
 

Session 1 Chair: Niklaus Wirth, ETH Zuerich, Switzerland 

9:00 - 10:00 Hardware and Software: The Closing Gap C.A.R. Hoare (Oxford 
University, United Kingdom) 

10:00 - 10:30 Is Oberon as Simple as Possible? Atanas Radenski (University of 
North Carolina, USA) 

Session 2 Chair: Hanspeter Moessenboeck, ETH Zuerich, Switzerland 

11:00 - 11:30 On the Essence of Oberon David A. Naumann (Southwestern 
University, Georgetown, USA) 

11:30 - 12:00 Adding Concurrency to the Oberon System Spiros Lalis, Beverly 
A. Sanders (ETH Zuerich, Switzerland) 

Special session in honor of Niklaus Wirth on his 60th birthday Chair: Carl August 
Zehnder, ETH Zuerich, Switzerland This session is held in room HG F30 
(Auditorium Maximum) 

14:00 - 14:30 Greeting address Gustav Pomberger (University of Linz, Austria) 

14:30 - 16:00 Addresses of a personal nature C. A. R. Hoare (Oxford University, 
United Kingdom) Edward M. McCreight (Adobe, Palo Alto, USA) Anita and Bill 
Walker (East Central University, USA) and others 

Apero 

PROGRAM COMMITTEE 

J. Gutknecht, ETH Zuerich, CH (Chairman)
R. P. Cook, Microsoft, USA
G. Coray, EPF Lausanne, CH
O. J. Dahl, University of Oslo, N
E. W. Dijkstra, University of Texas, USA
G. Goos, TU Karlsruhe, D
S. Graham, UC Berkeley, USA
D. Gries, Cornell University, USA
D. Hanson, Princeton University, USA
B. Kernighan, AT&T Bell Labs, USA
B. W. Lampson, DEC SRC, USA
J. Ludewig, TU Stuttgart, D
J. Misra, University of Texas, USA
H. Moessenboeck, ETH Zuerich, CH
R. Needham, Cambridge University, UK
S. Owicki, DEC SRC, USA
G. Pomberger, University of Linz, A
P. Rechenberg, University of Linz, A
M. Reiser, IBM Research, CH
B. A. Sanders, ETH Zuerich, CH
P. Schulthess, University of Ulm, D
A. Shaw, University of Washington, USA
A. Tanenbaum, Vrije Universiteit Amsterdam, NL
P. D. Terry, Rhodes University, SA
L. Tesler, Apple Corp., USA
J. Welsh, University of Queensland, AUS
N. Wirth, ETH Zuerich, CH

ORGANIZING COMMITTEE

C. A. Zehnder, ETH Zuerich (Chairman)
W. Gander, ETH Zuerich
M. Franz, ETH Zuerich

CONFERENCE SECRETARIAT AND STAFF

H. Guelguen,  ETH Zuerich
M. Bernard,   ETH Zuerich
I. Noack,        ETH Zuerich

LOCATION ETH Zuerich (main building HG), Raemistrasse 101, Zuerich, 
Switzerland Regular sessions: room HG F1 (F floor) Friday afternoon session: 
room HG F30 (Auditorium Maximum, F floor) 

Trains run every 10-15 minutes from the Zuerich airport to the central railway 
station and cost about CHF 5. A taxi from the airport to the center costs about 
CHF 40. From the central railway station take the tram (3 stops) to "ETH 
Zentrum" next to the ETH main building: either tram 6 (direction Zoo) or tram 10 
(direction Seebach). No parking is available at ETH. 

INFORMATION PLSA'94, ETH Zentrum, CH-8092 Zuerich, Switzerland Phone: 
+41-1-632 7311, Fax: +41-1-261 5389, E-Mail: PLSA94@inf.ethz.ch 

REGISTRATION, CONFERENCE DESK Use the enclosed registration card. For 
late registration at the conference desk we charge additional CHF 50. The 
conference desk (in fron00 to 17:00 on Wednesday and from 8:45 to 17:00 on 
Thursday and Friday. 

ACCOMODATION Hotels can be reserved using the enclosed hotel reservation 
card. 

LUNCHES Lunches can be taken in the ETH restaurant "Polyterrasse" (Mensa) 
which is in the main building (B floor, southern elevators). Don't forget your 
lunch tickets that you will get at the conference desk. 

CONFERENCE BANQUET The conference banquet will be held on Thursday, 
March 3, 19:00, at the Hotel Zuerich (Neumuehlequai 42) which is within walking 
distance from ETH. Banquet tickets at CHF 70 each have to be ordered with the 
conference registration. 

PROCEEDINGS AND BOOKS The proceedings are published by 
Springer-Verlag. One copy is included in the conference fee. Additional copies 
can be purchased at the conference book desk that will also show a selection of 
books related to the conference field. 

EXHIBITION Hardware developed at ETH Zuerich will be shown in the J floor of 
the RZ building, Clausiusstrasse 59. The exhibition will be open on conference 
days until 22:00. -- Send compilers articles to compilers@iecc.com or {ima | 
spdcc | world}!iecc!compilers. Meta-mail to compilers-request@iecc.com. 

________________________________________________________________

IMPRESSUM: The ModulaTor is an unrefereed journal. Technical papers are to be taken as working papers and personal rather than organizational statements. Items are printed at the discretion of the Editor based upon his judgement on the interest and relevancy to the readership. Letters, announcements, and other items of professional interest are selected on the same basis. Office of publication: The Editor of The ModulaTor is Guenter Dotzel; he can be reached by tel/fax: [removed due to abuse] or by mailto:[email deleted due to spam]
  ModulaWare home page   The ModulaTor download