The state of the M O D U LA-2 standard

Roger Henry describes some major language changes and clarifications introduced in the Third Working Draft

The Third Working Draft of the Modula-2 International Standard has been registered with the International Standards Organization (ISO) as a draft proposal Succes- sive drafts have been prepared by the British Standards Institute (BSI) Modula-2 panel IST/5/13 as guided by consensus decisions of the ISO/IEC working group JTC1/ 5C22/WC13. In the proposed standard, the semantics of conforming MODULA-2 programs, and of standard fibrary modules, are formally defined using the denotational specification language VDM-St_ The semantics are also described by an informal English language definition. Apart from delivering the specified behaviour for programs, certain conformance requirements are imposed on implementations of MODULA-2. The paper summarizes major language changes and clarifications including rules for use before declaration, import and export, numeric types and conversions, set types, structured value con- structors, open arrays and protected modules.

programming languages standards MODULA-2

With the publication of a draft proposal for the ISO/IEC Modula-2 Standard, it is appropriate to review the state of the standardization effort. This paper outlines the form of the emerging standard for MODULA-2 and summarizes the major language changes and clarifications agreed by the ISO working group. Some recent decisions of the UK drafting body, the BSI panel IST/5/13, are also described. These are subject to approval, or modification, by the ISO group. At the time of writing, the whole proposal is under- going the process of letter ballot whereby national standards bodies register their approval or disapproval of the draft proposal as the basis for the next stage of standardization which is the production of a draft inter- national standard for MODULA-2. Little attention is given

Department of Computer Science, University of Nottingham, Notting- ham NG7 2RD, UK The version of this paper presented at the 1st International MODULA-2 Conference, Bled, Yugoslavia, in October 1989, was based on the second working draft of the MODULA-2 standard. The present version includes revisions to reflect the third working draft of the MODULA-2 standard which has since been published by ISO as a draft proposal

here to the important areas of conformity clauses, system modules and separate library modules. It is hoped that future papers will be able to correct this. A review of the problems with the language is given by Cornelius 1.

This is a personal paper and so subject to the personal bias and misconceptions of the author who accepts full responsibility for the statements included. The true state of the standard is reflected in many working papers, in minutes of meetings, in drafts of the standard and in the minds of the many contributors.

S T A N D A R D I Z A T I O N PROCESS

The MODULA-2 panel of the BSI programming languages committee has been working on the standardization of MODULA-2 since November 1984. In 1986, the UK member body submitted a new work item proposal to the pro- gramming languages subcommittee of the ISO (then TC97/SC22) to coordinate the production of an inter- national standard for MODULA-2. There were three parts to the proposal: the production of requirements clauses for conforming implementations, the definition of the language, and the definition of a standard library. On a letter ballot, the work item gained the support of a sufficient number of participating members of SC22. A working group, WG13, was established and the first meeting was convened in April 1987.

WG13 has effectively given the BSI panel the res- ponsibility for preparing drafts of the standard, although some members of WG13 have also contributed sections. At the working group level within ISO, members act as individual experts, although account is taken of likely national body views. Several countries, including the USA, France, Canada and Germany, organize groups to coordinate input to the working group. There are no formal votes; the process is one of working to achieve consensus. At the subcommittee level within ISO, the procedure is more formal. The votes and comments express national views that may have been canvassed from a wider group than has contributed to the working group process.

The first relatively complete working draft was pre- pared for the WG13 meeting held in Linz in July 1989. A second working draft was then produced for con-

0141-9331/90/03133-11 © 1990 Butterworth & Co. (Publishers) Ltd

Vol 14 No 3 April 1990 133

sideration by SC22 at its plenary in Berlin in late Sept- ember 1989. Approval was given there for the registration of a more complete third working draft as an ISO draft proposal for MODULA-2. This was ready by the end of October 1989, and published in November 19892 . Participating member bodies of ISO/JTCl SC22 have a three month period in which to make formal comments and to vote on the acceptability of the draft in progress towards a draft international standard (DIS), with the ballot period due to end on 2 March 1990. The next WG13 meeting is planned for May 1990 when comments on the draft proposal, and proposed responses, will be discussed.

CONFORMANCE

A significant part of the standard deals with the con- formity clauses for implementations of MODULA-2. Account has also been taken of the reports of other SC22 working groups on guidelines for the production of programming language standards (WG10) and on the production of conformity clauses (WG12).

The conformity clauses turn a language specification into a document that can be used as the basis for con- tractual agreements between a supplier and a purchaser. They also give the basis on which validation services may be run. Conformity clauses that are relevant to the topics in this paper are summarized as the need arises. In the standard, they are dealt with together in one section.

LANGUAGE SPECIFICATION

The MODULA-2 standard is the first international standard to define the semantics of a programming language in a mathematically rigorous manner. The specification method adopted is aform of denotational semantics as used in the Vienna Development Method (VDM) 3. The principal author of the formal definition is Derek Andrews. The method is illustrated here using extracts from the second working draft showing the specification of if state- ments.

Concrete syntax

A program that conforms to the proposed MODULA-2 standard must, of course, be syntactically correct. To define the so-called concrete syntax of the language the standard uses the British Standard BS 6154: 1981, Method of defining syntactic metalanguage. This is similar to, but not identical with, the Extended BNF form used in the M O D U L A - 2 r e p o r t s .

The concrete syntax rules govern the textual appearance of MODULA-2 programs but cannot formally express all of the constraints. For example, as seen in Figure 1, the con- ditions in an if statement must be Boolean expressions but as far as the concrete syntax is concerned a Boolean expression is just an expression, the same as any other type of expression.

if s tatement = guarded statements, [ =ELSE", statement sequence ], "END" ;

guarded statements = "IF", Boolean expression, "THEN', statement sequence, { "ELSIF", Boolean expression, "THEN", statement sequence } ;

Figure 1. Concrete syntax of if statements

]f-statcrncnt :: s-thens ; scq of Guar(lcd-staterncnt s-e]sep : [ 5tatemcnt-ssqucnc¢ ]

Guarded-statement :: s-guard : Expresston s-body : ~tatement-sequence

Annotation. An i f statement always contains at least one statement sequence clause (which f o l l o w s the f i rst occurrence of a THEN symbol); thus af ter translation to the abstract syntax there is always a non-empty sequence o f guarded statements. A missing ELSE clause in the concrete syntax is denoted by nil in the abstract syntax.

Figure 2. Abstract syntax of if statements.

To hint at these constraints, and to help the reader, a degree of redundancy is deliberately introduced into the rules. In the concrete syntax for the if statement, the extra rule for guarded statements is also redundant, and does not have a corresponding rule in the MODULA-2 reports. It is introduced to make a closer correspondence between the conventional concrete syntax and the so-called abstract syntax needed for the formal definition of M O D U L A - 2 .

Abstract syntax

The abstract syntax abstracts from the details of the textual representation to express the underlying structure of the language. This abstract representation uses the conventional objects of discrete mathematics such as sequences and sets.

Figure 2 shows how abstractly an 'If-statement' is represented as a structure with two components. One component, which can be selected by 's-thens', is a sequence of another structure, called a 'Guarded-state- ment'. The other component, which can be selected by 's-elsep', is optionally a structure called a 'Statement- sequence' or is the 'nil' value. The notation adopts the familiar square brackets to show this optionality. There is always an else part in the representation of an if state- ment, but if there is no else part in the text, the abstract representation will be 'nil'.

The standard does not spell out the translation from concrete to abstract syntax since usually there is a direct relationship. As pointed out above, the form of the concrete syntax is chosen to make the correspondence as close as possible. On the few occasions that it is necessan/, the standard includes an informal (English) annotation explaining the correspondence. For the if statement, it is pointed out that 's-thens' cannot be an empty sequence since the concrete syntax demands at least one statement sequence following the first 'THEN' symbol.

It is interesting to note that because of the use of an abstract syntax giving the underlying structure of the language, the standard will be applicable to advanced graphic development environments, where there may be no conventional textual representation of a program, and to other software engineering tools.

Static semantics

The further constraints that apply to syntactically correct programs, sometimes hinted at in the concrete syntax, are specified in the standard as static semantics.

An informal natural language specification of the static semantics is given first. This is followed by the corres-

134 Microprocessors and Microsystems

The type of the Boolean expressions shall be of the required Boolean type.

WF : I f - s t a t e m e n t -* Env t ronmsn t -* B

W F [ m k - I f - s t a t e r n e n t ( t h e n s , e i s e p ) ] p •

(Ymk-Ouardsd-statement(gusrd,hocly)(elemsthsns • W F [ g u a r d ] p ^

T E [ g u s r d ] p = B o o l e a n -

W F [ b o ( i y ] p ) ^

( e t s e p = n t l v W F [ e | s e p ] p )

Figure 3. Stat ic s e m a n t i c s o f if s ta temen ts

ponding formal specification in the mathematical notation of the VDM specification language, VDM-SL The intention is not to burden the natural language specification with an attempt at completeness or lack of ambiguity. It is kept reasonably simple because of the existence of the formal definition which is intended to be complete and un- ambiguous. If the two forms of specification are found to conflict, there is a mistake in the standard.

The form of the natural language is constrained by rules governingthe production of international standards. Most notably, the rules require the use of the term 'shall' in clauses stating requirements. Here, the requirements are those imposed on a conforming program.

For the i f statement, the static semantics require all of the expressions to be Boolean expressions. In the formal definition shown in Figure 3, this requirement is part of the mathematical function WF (for Well-Formed) which, given the abstract representation of an if statement, produces a function from a so-called e n v i r o n m e n t to a truth value. An environment, in this context, is essentially a model of the symbol table in a compiler. It allows the meaning to be discovered of an identifier that is known in that environment - the kind of object that the identifier names and, if appropriate, the type and value of that object.

Dynamic semantics

The effect of executing well-formed constructs is given in the standard as d y n a m i c seman t i cs . Again, both a natural language and a formal specification are given.

The English 'shalls' now imply a requirement on an implementation in executing a conforming program.

Again using the if statement, for illustration, Figure 4 shows the formal definition is in the form of a mathematical function M (for Meaning) which, given the abstract representation of an if statement, produces a function from a (hidden) state to a new state in a given environment.

The state is essentially a mathematical model of internal and external storage-notably the values of variables. The meaning of a particular if statement, in a particular environment, is given as the transformation produced from the previous state to the following state.

THE LANGUAGE When identifying language changes, there is some difficulty since there are differences between the reports contained in various editions of the source text Pro- g r a m m i n g in M o d u l e - 2 . The edition normally used as a reference by the standardization groups has been the third, corrected edition of 19854 . On points where the editions differ, the standard notes language clarifications rather than language changes.

No attempt is made in this paper to catalogue all of the

The Boolean expressions of the sequence of guarded statements shall be evaluated in the order they occur until one of the Boolean expressions yields true; and then the associated statement sequence shall be executed. If all the Boolean expressions evaluate to false, the statement sequence of the ELSE clause (if present) shall be executed. An if statement shall denote no action if all the Boolean expressions evaluate to the value false and there is no ELSE clause. Note: The evaluation of the Boolean expression could produce a transformation of the program state Le. have a side-effect

H ; I f - s t a t e m e n t -* Env i r onmen t ..~

M [ r n k - ] f - s t a t e m e n t ( t l l s n s , e l s s p ) ] p i

t f thens = [] then

e x e c u t e - e l s e - s t a t e r n e n t s ( e l s e p ) p

e l s e

l e t r n k - G u a r ( l e d - s t a t e m e n t ( g u a r c I , b o c l y ) = h d t h e n s tn

def value : r l [ g u n r d ] P ;

t r va lue then

M[bodw]p ¢18¢

H [ m k - Z f - s t a t e r n e n t ( t i t h e n s , e t s e p ) ] p

e n d - t f

e n d m t f

Annotation: If there are no more elements remaining in the sequence of guarded statements then the ELSE of the if statement (if present) is executed. If there are more elements remaining in the sequence of guarded statements, the Boolean expression of the first guarded statement in the sequence is evaluated and if the result is true, the corresponding statement sequence is executed. If the result of the evaluation of the Boolean expression is false, then this element is removed from the sequence of guarded statements and the remainder of the sequence executed.

Figure 4. D y n a m i c s e m a n t i c s of if s ta temen ts

changes, or to give complete rationale for the positions that have been adopted. Instead, major areas of interest are selected and the proposals for the standard are summarized.

Ordering of declarations

Apart from the special case of pointers, the rule given in the reports for the ordering of declarations within a procedure or module block is:

If an identifier x defined by a declaration D1 is used in another declaration (not statement) D2, then D1 must textually precede D2.

The implication is that an identifier may be used in a statement that textually precedes the declaration of that identi f ier- provided, of course, that the statement falls within the scope of the identifier.

As is well known, the ordering rule allows, amongst other things, for mutually recursive procedures and for a program layout in which detail comes later rather than earlier in the text. As is also well known, implementation of the rule effectively requires a compiler to make more than one scan of a program or implementation module before code can be generated.

A large section of current practice departs from the report in that widespread use is made of single-pass compilers. These implement a more restrictive ordering rule in which the declaration of an identifier must also precede its use in statements. However, the accepted language is also extended by the introduction of a forward declaration for procedure headings. This is necessary to allow mutually recursive procedures to be declared.

For a long time, it was unclear how this situation could be reconciled so that a single MODULA-2 standard could be of use to both the multipass and the single-pass

Vol 14 N o 3 A p r i l 1 9 9 0 135

PROCEDURE P;

BEGIN

x := 1

END P;

VAR

x: INTEGER:

Figure 5. Use of x before declaration

implementor and user communities. An agreed solution has now been adopted which allows two kinds of implementation to conform to the standard in a way that does not compromise the conformance requirements or the ability to carry out validation tests.

An implementation may support declare-before-use static semantics ('single-pass') or declare-before-use-in- declarations static semantics ('multipass'). If the former, conforming programs with multipass dependencies may be rejected (essentially as too complex for the implemen- tation) provided that an appropriate message, indicating that there is a dependency, is eventually given. The reserved word FORWARD is also introduced into the language and must be checked and correctly processed by all conforming implementations.

It should be pointed out that not only is this a change from the report, it is also a change from current single-pass practice. Assuming that no otherx is visible in the scope of the x shown in the program fragment of Figure 5, the fragment must be accepted by a multipass implementation as well-ordered.

A conforming single-pass implementation may com- plain (erroneously) at the use of x in P that the identifier is not declared (since it has not seen the declaration yet). However, when it does eventually see the declaration, it must recognize that it is not well-ordered on the declare- before-use rule and give a unique and distinct message to that effect. Figure 6 shows another example to underline this point.

A conforming single-pass implementation might accept the assignment to x in Q, and generate code to assign to the x declared before P since it assumes that it is that x that is in scope at that point. When it eventually sees the declaration of x within P, it must recognize that it is not well-ordered on the declare-before-use rule and reject the compilation unit.

Such an approach is vital if we are to avoid having programs accepted as well-formed by both kinds of implementation and yet executed with different dynamic semantics-that is, if we are to avoid having two languages.

Ordering of pointer and procedure type declarations

In the reports there is an explicit exception from the declare-before-use-in-declarations rule, for the declara- tions of pointer types:

Atype TI can be used in a declaration of a pointer type T which textually precedes the declaration of TI, if both T and TI are declared in the same block.

This rule is needed to allow, for example, the declaration of a record type that has a field type that is a pointer to that record type. This is much used in the construction of dynamic data structures such as lists and trees.

The rule, as formulated, not only allows the type T to

VAR

x: INTEGER:

PROCEDURE P;

PROCEDURE Q:

BEGIN

X := 1

END Q;

VAR

x: INTEGER;

BEGIN

x := 2

END P;

Figure 6. Use, in Q, before declaration of x in P

TYPE

T ~ POINTER TO TI;

VAR

x, y: T;

PROCEDURE P ;

BEGIN

x := y; (* case A *)

x ~ := y^; (* case B *)

x ~ := i (* case C *)

END P;

TYPE

T1 3 INTEGER;

Figure 7. Ordering statements with forward-reference type declarations

be used in the declaration of other objects before the type T1 has been declared, but also allows those other objects to be used in statements. Consider Figure 7 where T and T1 are indeed declared in the same block.

Cases B and C would arguably create problems for single-pass implementations but not for multipass implementations. The dereferencing in these cases is essentially a use of the type T1 before it has been declared and a conforming single-pass implementation must report it as a multipass dependency. This situation is very similar to one which can arise with the full declaration of opaque types, of which more later.

The phrase 'declared in the same block' would seem to rule out the legality of the fragment shown in Figure 8 since T1 is declared in the block of the module M and not in the same block as T. However, it could be argued that this is against the spirit of the understanding that modules serve only to control the visibility of identifiers. A slightly more liberal rule would allow this example. A suitable wording would be that:

T1 must be known before the end of the block in which T is declared.

TYPE

T - POINTER TO TI;

MODULE M;

EXPORT TI:

TYPE T1 - INTEGER;

END M;

Figure 8. T7 is not declared in the same block as T but is k n o w n within it

136 Microprocessors and Microsystems

TYPE

T - PROCEDURE(CHAR, VAR T);

Figure 9. A procedure type with a parameter of the same type

The formal definition in the third working draft checks the original, less liberal, rule. Again there is a comparison later with a similar situation which arises in the full declaration of opaque types.

Procedure types

MODULA-2 introduces another class of data type for which self reference is desirable- the procedure type. For example, a type such as T in Figure 9 would allow the declaration of a procedure, P, which could give itself as the value of its result parameter. Or it could give another procedure Q, of the same type, as the result where Q gives P as its result. An application is in the construction of procedures corresponding to the states of a finite state machine, where the result parameter is the next state to be entered.

The MODULA-2 reports do not contain an exception to the declare-before-use-in-a-declaration rule that would allow such a type to be declared. The proposed standard does allow such declarations, however, and the proposed standard input/output library makes use of this to define an input scanning procedure, 'Readltem', which takes the start state of an arbitrary finite state machine as one of its parameters.

The rules for using an identifier that has not yet been declared in the declaration of a procedure type are intended to fol low exactly the corresponding rules for pointer types.

Procedure operations and constants

While on the subject of procedure types, it is worth noting that the standard also extends their usefulness by allowing tests of equality and inequality on procedure values. The standard follows the third report in defining a constant expression as an expression in which all the terms are constants and any function calls are calls of standard (intrinsic) functions. A procedure identifier is a constant and may be used in a constant declaration. This has particular application in a definition module since it effectively allows the re-export of procedure identifiers. This use is illustrated in Figure 10.

Opaque types

The reports require the full specification of an opaque type to appear within the corresponding implementation

DEFINITION MODULE MyLib;

IMPORT IO, WholeIO, RealIO;

CONST

WriteLn - IO.WriteLn;

WriteInt - WholeIO.WriteInt;

WriteReal = RealIO.WriteReal;

END MyLib.

Figure 70. Procedure constants allow procedures to be re-expoSed

module. In the third edition, opaque export is restricted to pointers.

The proposed standard effectively interprets these requirements as a rule that an opaque type must be known as a pointer type by the end of the corresponding implementation module block. This allows the full declaration to be contained in a nested module from which the name of the opaque type is exported. The rule therefore corresponds to the liberal rule described above for the declaration of bound (pointed to) types. (Imp- lementors please no te - the same interpretation applies to the full declaration of procedures defined in the definition module. The full declaration may occur in a local module nested within the implementation module, provided it is made visible by unqualified export to the implementation module block.)

Further, the full declaration does not have to be as a new type. The opaque type can be defined as identical to an existing, possibly imported, pointer type, including 'SYSTEM.ADDRESS'.

As a further clarification of the rule for opaque types, it is acceptable for an opaque type to be known at the end of the implementation module block as an opaque type. Thus the full declaration may show an opaque type to be identical to another opaque type, either imported from a separate module or defined as such in the corresponding definition module. This is most useful in allowing opaque types to be implemented in terms of other opaque types.

If an opaque type happens never to be used in the corresponding implementation module in a way that requires knowledge of the bound type, the current formal definition does not require the full declaration to appear. After all, the opaque type will be known as an opaque type by the end of the implementation module block. Usually, however, the bound type will be used and then we have the possibility of multipass dependencies. The cases illustrated in Figure 11 are very similar to those given in Figure 7 for pointer types.

A conforming single-pass implementation must reject cases B and C eventually diagnosing the problem as a multipass dependency. A conforming multipass imple- mentation must accept these cases.

Import and export

The notion of import and export to and from modules is at first a deceptively simple one. The detailed semantics

DEFINITION MODULE M;

TYPE

T;

END M.

IMPLEMENTATION MODULE M;

VAR

x, y: T;

PROCEDURE P;

BEGIN

x :- y; (* case A *)

x ̂ :- y~; (* case B *)

x ̂ :- 1 (* case C *)

END P;

TYPE

T - POINTER TO INTEGER;

END M.

Figure 77. Use of an declaration

opaque type before its full

Vol 74 No 3 April 1990 737

MODULE M;

EXPORT N;

MODULE N;

EXPORT x;

VAR

x: INTEGER;

BEGIN

END N;

BEGIN (* M *)

X := i:

N.x :- 2

END M;

Figure 12. Unqualified export from a local module

have been at issue within the ISO, BSI, and other groups for several years. Consensus on the model to adopt has now been reached and the implications of that model are described here.

Most of the controversy has concerned the case of unqualified export from a local module. In Figure 12, the qualified identifier N .x is allowed even though x is exported unqualified from N. In fact, this form may be used whenever N is in scope (this cannot be inside module N itself). The effect of qualified export may therefore be understood as restrictingthe external names for x to exclude the unqualified form.

What is the effect of the export of N from M? Does it make the unqualified form, x, available outside M as explicitly allowed in earlier editions of the report? The answer is no. However, since the module name N is visible outside M, the qualified form N. x is legal in that context.

Numeric types and conversions

The position on numeric types was reached after much debate. One of the main concerns was the portability of programs using numeric types.

Whole number types

The starting point for whole number types gives us 'CARDINAL' and 'INTEGER' as pervasive identifiers for two basic types - the first taking values from 0 to 'MAX (CARDINAL)', the second taking values from 'MIN (INTEGER)' to 'MAX (INTEGER)'. To avoid confusion over the fact that the standard identifiers for these types may be redeclared, the basic types are referred to in the standard by their unique type names unsigned-type and signed-type. Values of these two types may not be mixed in expressions, but, as a special case, the types are assignment compatible.

There are no literal values of these two types. Instead, whole number literals are given a conceptual type with the unique type name ZZ. There is no identifier available for this type, so it is not possible to declare variables of type ZZ. There may be expressions of type ZZ and these will always be constant expressions. For example, in the constant declaration of Figure 13 the -1 is a constant expression of type ZZ (not a literal because of the negation operator). The constant 'minus1' is also of ZZ type and therefore may be used in other expressions of type ZZ.

The allowed range of values of ZZ supported by an implementation must encompass at least the ranges of

CONST

minusl = -I

Figure 13. A constant of type ZZ

the signed type and the unsigned type. (The supported range may be greater to avoid overflow in the computation of intermediate results in constant expressions.) Values of type ZZ may be mixed in expressions with the signed type, giving a result of the signed type, or with the unsigned type, giving a result of the unsigned type.

The standard does not introduce any other basic whole-number types with their own pervasive identifiers, thus there is no 'LONGCARD', 'SHORTCARD', 'LONG INT', or'SHORTINT'. Instead, it is assumed that for numeric applications, users will declare explicit sub- ranges. The implementation may take advantage of this to optimize storage or to utilize the most efficient hardware operations. Although, at first sight, it may seem that a conforming implementation may allow a subrange with limits of type ZZ outside the range of the signed type or the unsigned type, this is in fact not the case. All numeric subranges have a host type which is either the signed type or the unsigned type. The range of these types should therefore be chosen by an implementation as the largest range for which it is prepared to implement arithmetic at run time. Another consideration for an implementation is that the result of the standard function procedure 'HIGH' is of the unsigned type.

Values obtained from a host type and any of its subranges may be mixed in expressions. In fact, the standard interprets values of a subrange type as values of the (top-level) host type in an expression context. One way to think of this is that a variable of a subrange type may only take on values within that subrange but those values are actually values of the host type of the subrange.

Certain standard function procedures return results of type ZZ. Thus 'MAX' and 'MIN' applied to whole-number numeric types, including subranges, produce a result of type ZZ which may therefore be used as though it were a literal value. ABS produces a result of type ZZ when applied to an expression of type ZZ. SIZE always returns a result of type ZZ which therefore may be mixed with values of the signed type or the unsigned type in expressions.

Real number types

For real number types, it was thought appropriate to provide for two precisions. Therefore the standard requires a conforming implementation to provide 'REAL' and 'LONGREAL' as pervasive identifiers for the basic scalar real type and long-real type. A conforming imple- mentation could implement both real number types using the same underlying representation provided it treats them as logically distinct types. Since they are distinct types, they may not be mixed in expressions and are not assignment compatible.

The problem of real number literals is dealt with by introducing another internal type for them called RR. Values of this type are compatible with both the real type and the long-real type.

Conversions

One of the insecurities of the report is that type names may be used as type transfer functions in which the bit

138 Microprocessors and Microsystems

pattern representing a value of one type is interpreted as a value of the named type. In the standard, this system- dependent functionality is dispatched to the module 'SYSTEM' as the function procedure CAST. At one time, it was proposed that the old syntax could then be used to give the safe semantics of converting the representation to give an appropriate value of the named type. Eventually itwas agreed that the old syntax should not be used in the standard, thus leaving it available for implementations that wish to provide the original semantics as an extension (in a non-standard mode of operation).

What we have instead is the standard function 'VAL', which takes care of all legal conversions, and, for convenience, the functions 'FLOAT', 'INT', 'LFLOAT', and 'TRUNC' which respectively achieve the same results as 'VAL' for the result types 'REAL', 'INTEGER', 'LONGREAL', and 'CARDINAL'. For the case of these numeric con- versions (apart from 'TRU NC'), the type of the value to be converted may be any numeric type. For example, 'INT' is used to convert values of type ZZ, the unsigned type, and both real number types to an appropriate value of type 'INTEGER'. This means that the form 'INT(1)' may be used to force interpretation of a literal as a value of type 'INTEGER'.

The conversion functions 'CHR', producing 'CHAR' from any whole number type, and 'ORD', producing the unsigned type from any ordinal type, are also defined.

Set types

Set types are not dealt with very well by the language reports. There is no semantics given for set constructors which appear only in the concrete syntax for expression. The use of sets is also limited by their assumed representation as bits in a machine word.

A very early decision during standardization was that the type 'BITSET', needed for low-level bit operations, should be treated differently from more general sets. Because of its system-dependent characteristics and assumed representation, it has to be imported from 'SYSTEM' under the proposed MODULA-2 standard. The qualified identifier before a set constructor is not optional. To construct a value of type 'BITSET', this identifier must be imported from 'SYSTEM'.

There is now no need to introduce limits on the range of ordinal values specified in the base type of a user- declared set type. There is no assumed representation for such types. In particular, it is not assumed that the inclusion of a value with ordinal number n will be represented by the value of a bit number n in a machine word. Indeed one of the proposed conformance clauses would impose a lower limit on the maximum size of a set such that 'SET OF CHAR' would be accepted. This may have to be expressed as a more modest value, such as 256, in view of the emergence of standards for large character sets.

TYPE

R -

RECORD

name: ARRAY [0..19] OF CHAR;

score : CARDINAL;

END ;

CONST

C - R{"James", 15};

Figure 14. Record value constructors

The standard adopts the change in the third edition of the report which allows the elements of set constructors to be general expressions. They are therefore constructors of set values and not just set constants. The elements are required to be of a type that is assignment compatible with the base type of the set type.

Structured value constructors

The standard does not classify the set types as structured types but as elementary types-a long with procedure types, scalar types, opaque types, and pointer types. The structured array and record types have no value con- structors in the language defined in the MODULA-2 reports. The MODULA-2 standard introduces constructors for array and for record values.

The concrete syntax is developed from that for set value constructors. A type name is followed by a list of expressions enclosed in {} braces. Correspondence is established component by component for arrays and field by field for records, the type of the given expression being assignment compatible with the component type or with the corresponding field type. In the case of tag fields, the corresponding expression in the value con- structor must be a constant expression. In the case of tagless variants, a constant tag value must still be given in the constructor. Structured value constructors must be complete - there can be no missing trailing values. Figure 14 illustrates some of these rules.

The draft proposal provides a limited form of anonymous value constructor. This allows the construction of an array value of a type that was declared with an anonymous component type. Figure 15 shows how an abbreviated form of array type declaration may be followed by a constructor for a value of that type.

The abbreviated form of constructor may be used even if the component type is not anonymous. Similarly, values may be constructed of an array type without specifying the type of component record values, and values may be constructed of a record type without specifying the type of record fields or array fields. There is no ambiguity for the translator because the whole structure is typed.

A simple form of replicator is to be allowed in the construction of structured array values. The form is illustrated in Figure 16. The repetition count following'BY' must be a constant expression.

Since function calls in constructors, as elsewhere, may have side effects, it is important to note that, under these proposals, the expression giving the value to be replicated is evaluated once and only once. Thus A{ f ( )BY 3} generates one call of f at execution time whereas A [ f (), f (), f ( ) } generates three calls.

The standard does not, in general, define an order of evaluation for the operands in expressions. Any program that depends on such an implementation dependency is not a standard program, however few production com- pilers will be able to detect such a program reliably.

TYPE

A - ARRAY [1..3, 1..2] OF CARDINAL;

CONST

Table-A{{10, 11},{15, 16},{20, 21}}

Figure 15. Array value constructors with an anonymous component type

Vol 74 No 3 April 1990 139

TYPE

A - ARRAY [i..3] OF CARDINAL;

B - ARRAY [0..99] OF A;

VAR

x: CARDINAL;

y: A;

z: B;

BEGIN

x := i;

y := A{X BY 3};

z :- B{y BY 30,{0 BY 3} BY 70};

Figure 16. Array value constructors replicators

with value

The concrete syntax does not allow structured value constructors to be indexed or selected directly. However, indexing and selection may be applied to named constants of a structured type. This is important function- ality for structures like constant look-up tables. There is a consequent effect on the definition of value designators.

To complete this review of structured values, it is noted that the record designator in a 'WITH' statement may now designate a record constant.

Strings and things

The reader should not worry that there is a new type called 'THING'. Neither is there a new type called 'STRING'. Strings have posed several problems for the MODULA-2 standards groups but these have been resolved by other means.

There is a new type called SS. As with ZZ and RR, this is an internal type and has no user-accessible identifier. All string literals are described as having type SS and an associated length from O, for the empty string .... or " , through 1, for single character literals such as "A" or 'A', and upwards depending on the number of characters between the matching quotes.

Values of type SS and length n are assignment compatible with arrays having a component type of 'CHAR' and a number of components (capacity) greater than or equal to n. The index type is not restricted to a zero-based subrange as it is in the report since this restriction cannot be enforced for most of the operations on strings-since these are supplied by a string library module using procedures with open array parameters.

If the length of the string is less than the capacity of the array, the string terminator character is stored in the component following the last character in the string, or in the first component if the string is the empty string. The standard does not determine the internal representation of the string terminator. This is an implementation- defined value. It is represented in the text of a module as .... (or ' 9, that is by the empty string literal.

Values of type SS and length 0 or 1 are expression compatible with the type 'CHAR', allowing such usage as shown in Figure 1 7. Note that constants defined in terms of string literals are also of type SS.

When passed to an open array parameter with a component type of 'CHAR', a value of type SS and of length 0 appears as an array with a capacity of 1 containing the string terminator as its only component. The standard function 'HIGH' returns the value 0 in this case. Values of type SS and of length n greater than zero appear as an array of capacity equal to n with 'HIGH' returning a value one less than n.

VAR

ch: CHAR;

CONST

EOS - "";

BEGIN

ch := EOS;

IF ch = "A" THEN

END

Figure 17. Values of type SS compatible with CHAR

CONST

reply - "We didn't say" I I ' "No"':

escSeq - 33C ii "E";

both- escSeq 11 reply;

Figure 18. Extended string constants

A new intrinsic function with the pervasive identifier 'LENGTH' is proposed for the language. This returns the length of a string literal, a string constant, or a string value stored in an array. This extension seems appropriate given the importance of the length in manipulating strings. As for other standard functions, when applied to constants or literals, a call of 'LENGTH' can appear in a constant expression.

An extension is proposed to the syntax for string constants allowing simple concatenation of literals and constants of type SS. The consensus within the BSI panel is that an explicit punctuation symbol should be used as a separator, but this has not been discussed by WG13. The symbol used in the draft proposal is l I.

The 8SI panel is also now proposing that the numeric character literal form, such as 1OLC, should be seen as an alternative form to the string literal of length 1. That is, it should be confirmed as being of type SS. The main usefulness is to obtain a literal representation of control characters.

Some examples of the use of extended string constants are given in Figure 18.

Open arrays

The decision to allow multidimensional open arrays was taken relatively early in the standardization process.

The concrete syntax for a formal type becomes:

formal type = {"ARRAY", "OF"}, type identifier;

A matching actual parameter must have a corresponding number of dimensions to the formal parameter (unless the component type is a system storage type when special rules apply).

Within a procedure with an open array formal para- meter, the standard function 'HIGH' may be used to obtain the high bound of each open array or component open array. This is done by indexing, as necessary, to designate the required open array. Since open arrays have a low bound of O, the value 0 is always safe to use as the index.

The example of Figure 19 is adapted from one of the relatively few examples contained in the current draft (it is intended that more examples are provided in future drafts).

740 Microprocessors and Microsystems

Given:

TYPE Colours- ARRAY (red, yellow, green) OF REAL;

VAR a: ARRAY [-7 .. 2] OF ARRAY BOOLEAN OF Colours;

PROCEDURE P ( f: ARRAY OF ARRAY OF Colours

);

for a call of P(a).

HIGH(f) has Thc valne 5 HIGH(f [0] ) has th~ value ] HIGH ( f [ 0, 0 ] ) is iUeg~d since the U~/rd dimension J$ not an open an'a),

Figure 19. Multidimensional open array parameters

Protected modules

The report allows an optional priority to appear in the headings of program modules, implementation modules and local modules. This specifies the processor priority that is to apply, with respect to external interrupt priorities, during the execution of statements within these modules. The effect of an interrupt in MODULA-2 iS defined to be an asynchronous coroutine transfer operation. Execution of a coroutine can be interrupted, 'if and only if the interrupting device has a priority that is greater than the priority level of the module containing the statement currently being executed'.

The proposed standard defines a required mechanism for coroutines which includes the facility of suspending execution, in favour of a nominated coroutine, until a specified interrupt occurs. This is applicable to all systems where there are external asynchronous events - not just device-level hardware interrupts but also operating system signals, for example. Protection against interrupts occurring at unwanted moments (before a coroutine has prepared to accept an asynchronous transfer, or where there may be interference between an executing co- routine and an interrupting coroutine) is dealt with by the standard as a special case of a more general protection scheme outlined here. The coroutine mechanism itself is defined in a system module (pseudo module) and is not the direct concern of this paper.

To implement the mechanism described in the report, compilers generate appropriate code as part of the prologue and epilogue of procedures that are exported from a protected module and of the statement part of that module. (For separate modules, the standard says that this part of the prologue comes after the initalization of any imported modules.) It has been argued that it should be possible to protect statements or statement sequences from interrupts without having to organize these state- ments into procedures declared within a module. The relevant prologue and epilogue code has therefore been made directly callable as the two new standard pro- cedures 'ENTER' and 'LEAVE' (for entering and leaving a so-called domain of protection). These procedures take one parameter which is the protection status of the domain that is being entered or left. When called indirectly, the actual parameter is supplied by the value of the constant expression which appears in the heading of a protected module.

The report does not mention the type of the constant expression that may appear in a module heading or the context in which the expression is evaluated. The standard requires the minimum funtionality for portability which is a type, 'PROTECTION', with two extreme values,

one which allows all interrupts through and one which allows none through. There are two corresponding required pervasive (standard) identifiers - 'INTER- RUPTIBLE' and 'UNINTERRUPTIBLE'. The standard pro- cedures 'ENTER' and 'LEAVE' take value parameters of type 'PROTECTION'.

Some properties of the type must be allowed to be defined by an implementation so that proper account can be taken of the underlying interrupt structure. Thus, if it is assumed that hardware interrupts are being dealt with, a complete ordering of numerical priorities might be appropriate for one machine and a partial ordering of interrupt masks might be appropriate for another. As an extension, an implementation may add further values to the protection type and provide a way of generating or denoting those values. This could be done in a way that allows compatibility with old source code. For example, a compiler for the original PDP-11 machine might make values of ZZ type assignment compatible with 'PRO- TECTION'.

A protection expression in the heading of a separate module may only use the appropriate pervasive identifiers or literal values defined by an implementation. For local modules, the protection expression is evaluated in the block in which the module is declared.

Now that 'ENTER' and 'LEAVE' are provided, the protection status may be specified dynamically - that is it may be computed at execution time. One reason for defining a pervasive identifier for the protection type is to allow the user to declare procedures with protection parameters that may be passed on to calls of 'ENTER' and 'LEAVE'. There are preconditions on the protection values supplied in such calls; for example, it is illegal to enter a protection domain that allows interrupts that are not already allowed. A standard function 'PROT' is defined which returns the current protection status. A conforming implementation is also required to provide the infix relational operators equal, unequal, greater than or equal, and less than or equal on values of the protection type. A value pl compares less than a value p2 if and only if pl allows all the interrupts allowed by p2 but p2 does not allow all the interrupts allowed by pl. Thus interruptible compares less than uninterruptible.

User-defined protection

Since they are standard identifiers, 'ENTER' and 'LEAVE' may be redeclared. The static semantics only require that in the block in which a (local) protected module is declared, 'ENTER' and 'LEAVE' designate proper pro- cedures with one parameter that is assignment com- patible with the type of the protection expression. Inside the domain of protection, the exported procedures and the module body will be protected by automatic calls to these user-supplied access procedures.

An obvious application for this scheme is in the construction of true monitors to operate in a multiprocess environment. The example shown in Figure 20 allows just one monitor, but it is fairly straightforward to program managers that can deal with statically or dynamically created multiple monitors. The illustrated use in Figure 21 is in the construction of a bounded buffer.

SYSTEM MODULES

Facilities in system modules, which are modules known to the compiler, are facilities that cannot otherwise be

Vol 14 No 3 April 7990 741

DEFINITION MODULE MonitorManager;

TYPE

MonitorProtection - (monitor);

PROCEDURE ENTER(m: MonitorProtection);

(* gain exclusive use *)

PROCEDURE LEAVE(m: MonitorProtection);

(* release exclusive use, pass it to any process waiting to regain use after signalling a condition

*)

TYPE

Condition;

PROCEDURE NewCondition(VAR C: Condition);

(* create a new condition, identified by new value of o

*)

PROCEDURE Signal(c: Condition);

(* unblock first process waiting for the given condition,

giving it exclusive use *)

PROCEDURE Wait(c: Condition);

(* join queue of processes waiting for the given condition, release use of the monitor

*)

END MonitorManager.

Figure 20. Defining domain access procedures for a monitor

expressed in MODULA-2, or which it would be inefficient to provide in separate modules, but which it is not thought appropriate to provide as a pervasive part of the language. This may be because the facilities are dangerous, or system dependent, or it may simply be to reduce the number of pervasive identifiers and to produce a coherent module that looks like an ordinary separate module to most users.

The proposed standard requires an implementation to provide three system modules. The first is 'SYSTEM' which has been generalized from the report, and from which facilities for coroutines have been removed. Implement- ations may extend but not reduce the facilities defined for 'SYSTEM'.

With the advent of machines with byte, word and long- word instructions and addressing, it has become necessary to find a way of generalizing some of the facilities of 'SYSTEM'. In the case of the 'BITSET' type, this has been done by introducing the bit number type, 'BITNUM', subranges of which may be used to construct new bit set types with properties similar to 'BITSET'. A new fixed name, 'LOC', has also been introduced for the smallest addressable unit of storage defined in 'SYSTEM'. 'BYTE' and 'WORD' may be defined in terms of arrays of 'LOC'.

The proposed 'SYSTEM' also defines procedures and functions for address arithmetic, for shift and rotate operations on bit set types, and for establishing a user- supplied procedure to be called on program termination.

The other two required system modules may not be reduced or extended by conforming implementations. One is 'COROUTINES'. This provides a coroutine mech- anism based on fixed identities for coroutines. The other is 'ReportExceptions' which provides a standard mech- anism for the reporting of exceptions. This is based on the

FROM MonitorManager IMPORT

monitor, ENTER, LEAVE;

IMPORT

MonitorManager;

MODULE Buffer[monitor]; FROM MonitorManager IMPORT

NewCondition, Signal, Wait;

EXPORT

Put, Get;

CONST

N = 128;

VAR

buff: ARRAY [I..N] OF CHAR; n: [0 .. n];

in, out: [i .. N];

nonFull: Condition;

nonEmpty: Condition;

PROCEDURE Put(ch: CHAR);

BEGIN

IF n = N THEN

Wait(nonFull) END;

INC(n); buff[in] :- ch;

in :- in MOD N +I;

Signal(nonEmpty) END Put;

PROCEDURE Get(VAR ch: CHAR);

BEGIN

IF n = 0 THEN

Wait(nonEmpty)

END;

DEC(n); ch := buff[out];

out := out MOD N + I;

Signal(nonFull) END Get;

BEGIN

n := 0; in := i; out := I;

NewCondition(nonEmpty); NewCondition(nonFull)

END Buffer;

Figure21. A bounded buffer module with monitor access procedures

implicit

reporting side of the exceptions proposals that were contained in the second working draft of the standard.

SEPARATE M O D U L E S

The standard distinguishes required separate modules from standard separate modules. The required modules must be provided by a conforming implementation with the semantics defined in the standard. In the draft proposal, these are 'Storage', 'HandleExceptions', 'Low- Real', and 'LowLong'. The latter two modules allow information to be obtained by a program on the properties of the 'REAL' and 'LONGREAL' types.

While WG13 is agreed that exception handling be provided for in the standard by a required separate library module, the model of exception handling supported by that module remains to be resolved. The second working draft of the standard described a scheme in which parameterless, level zero, procedures are invoked by a procedure named Call which is also passed the identity of an exception handling procedure. Although this is the current default position of WG13, it is fair to say that many members now regard its limitations to be unacceptable. The draft proposal describes this scheme in an annex, together with a new proposal recommended by the BSI panel, that is based on the facilities for user-defined access procedures in protection domains.

142 Microprocessors and Microsystems

In outline, the idea is that the exception handling module provides versions of 'ENTER' and 'LEAVE' that allow an exception handling procedure to be nominated. The handler is called if any exception is reported during the execution of a procedure that is protected by these access procedures. The protection expression is simply the name of the handler.

There is no requirement for a conforming implement- ation to provide the remaining standard modules. How- ever, if any module with a standard name is provided, or any part of a standard module, then the entire module must be provided with the semantics defined in the standard.

The modules defined in the draft proposal are the mathematics libraries 'RealMath' and 'LongMath', the input/output library, the modules 'Processes' and 'Sema- phores' for concurrent programming, the module 'Strings', the module 'Termination' which handles the execution of clean-up routines on program termination, and also 'SysClock' which gives access to a system clock.

COMMENTING ON THE STANDARD

Copies of the d raft proposal are available through national standards bodies within each participating country, such as BSI in the UK. Alternatively, the MODULA-2 panel in a country may make its own arrangements for copying and distribution. (Similarly, copies of the ISO Modula-2 Working Group documents are lodged with national standards bodies but it is likely that these may be obtained more quickly from the MODULA-2 panels.)

Concurrently with the ISO ballot on the draft proposal, the BSI issued the identical document as a draft for public comment. This will facilitate the eventual adoption of the ISO Standard as a British Standard. Comments are encouraged, particularly from those interested in MODULA-2 who have not yet participated in the standardization process. A method for collating individual comments is in place s .

To influence the formal comments and voting under-

taken at SC22 level, contact must be made with the appropriate organization in the relevant country. The SC22 Secretariat decides on the outcome of the vote whether there is sufficient support to allow the reg- istration of a suitably revised document as a draft inter- national standard. This is voted on at the Technical Committee level (JTC1). If there is insufficient support, a second draft proposal must be prepared and voted on again within SC22.

It is a good sign that consensus has been reached on so many issues and that work is now converging on an agreed standard for MODULA-2. The true mark of success will be the adoption of the standard by the implementors, teachers and users of MODULA-2.

REFERENCES

1 Cornelius, B J 'Problems with the language Modula-2' Softw. Pract Exper. Vol 18 (June 1988) pp 529-543

2 Third Working Draft Modu la-2 Standard ISO/IEC JTC1/SC22/WG13 document D106 ISO/IEC DP 10514

3 Bjorner, D A and Jones, C B Formal specif ication and software deve lopment Prentice-Hall (1982)

4 Wirth, N Programming in Modu la-2 (3rd ecL) Springer Verlag (1985)

5 Review Guidel ines for the Modula-2 Standard ISO/IEC JTC1/SC22/WG13 document D105

Roger Henry is a lecturer in computer science at the University of Nottingham where he teaches MOOULA-2 for introductory and system-level programming courses. He is a founder member of the BSI MODUtA-2 standardization panel and is convenor of the ISO MOr)ULA-2 working group ISO/IEC JTC1/SC22/WG13. His main technical contributions to the development of the MOOULA-2 standard have been in the design of the input~output library and in proposals for concurrent programming.

Vol 14 No 3 Apri l 1990 143

COiTIPW EURO qo TEL-AVIV, ISRAEL 7 - 9 MAY 1990

COMPUTER SYSTEMS and SOFTWARE ENGINEERING

SYSTEMS E N G I N E E R I N G ASPECTS OF COMPLEX COMPUTERIZED SYSTEMS

Tel-Aviv, Israel , 8-10 May 1990

26 Sessions and 70 Selected papers on:

* C O M P U T E R SYSTEMS ENGINEERING AND EMBEDDED C O M P U T E R SYSTEMS

* SOFTWARE ENGINEERING

,A- VLSI SYSTEMS

* RAPID PROTOTYPING OF SYSTEMS AND SOFTWARE

-k ARTIFICIAL INTELLIGENCE T E C H N I Q U E S

* DEVELOPMENT ENVIRONMENTS

* MANAGEMENT OF THE DEVELOPMENT PROCESS AND RESOURCES

3 Tutorials on:

* SOFTWARE PROJECT MANAGEMENT FOR EMBEDDED SYSTEMS - T H E EMPIRICAL SUCCESS FACTORS

* PROTOTYPING TOOLS, T E C H N I Q U E S AND CONCEPTS

* PRACTICAL VISUAL T E C H N I Q U E S IN REACTIVE SYSTEMS DESIGN, WITH ADA EXAMPLES

For full details please contact: CompEuro '90 Secretariat

PO Box 50432 Tel-Aviv 61500, ISRAEL

Tel: 972-3-664825 Fax: 972-3-660952 Tlx: 361142

744 Microprocessors and Microsystems