🚀 go-pugleaf

             Significant Changes to the Language Modula-2

                  M2WG-N94: Issue 2: 30th April 1986


                           Barry Cornelius

                    Department of Computer Science
                         University of Durham
                   Durham  DH1 3LE  United Kingdom



This paper gives a list of some of the changes being proposed by the
Modula-2 Working Group of the British Standards Institution.  The list
mainly consists of changes that are likely to affect existing Modula-2
programs.  The changes are provisional: formally, no decision has any
effect until ISO ballots on a draft proposal.  However, please mail me
if you think that any of these changes are undesirable.

In this paper, the notation "PIM" is used to refer to the book
"Programming in Modula-2" by Niklaus Wirth.  The Pascal Standard
(BS6192/ISO7185) is referred to by the notation "PS".  The definitions
of the terms 'ordinal type' and 'exception' are given in the paper
"Type Conversions in Modula-2" [2].

The section numbers used in this paper correspond to those used in the
"Report on The Programming Language Modula-2" (as given in PIM).


3. Vocabulary and representation

WG104:  It was agreed that underscores be permitted (as a 'break'
        character) in an identifier subject to:
        +    underscores are not permitted as the first or last
             character of an identifier,
        +    underscores are significant.

WG007:  MaxInt, MinInt, etc., are to be dropped as MAX and MIN make
        them redundant.

WG086:  It was agreed to remove:
             octalDigit $octalDigit "C"
        from the language, since CHAR(^^^) can now be used in any
        context in which ^^^C could be used - see WG099 in $5.

WG106:  Two proposals on "strings" have been discussed in detail.
        Briefly, these proposals are:
        (i)  assignment of a string constant of length f to a variable
             of type ARRAY [0..t-1] OF CHAR is permitted if f<=t.
             If f<t, each of the last (t-f) elements of the array
             variable is assigned the value which is defined by the
             constant StringTerminator in the module SYSTEM.
        (ii) a new string data type is introduced.
        It is possible that either or both of these proposals will be
        accepted.  The views of the Modula-2 community are to be
        sought - see the paper "All About Strings" [3].

WG012:  It was agreed to add NIL as a reserved word.






                              - 2 -


5. Constant declarations

WG099:  It was agreed to take the definition of constant expression
        given in a paper by Don Ward (M2WG-N52).  Informally, this
        definition is:
             Each operand in a ConstExpression must be a constant.
             A constant is:
             +    a literal (either a number, a single
                  character or a string literal),
             +    an identifier denoting a constant value
                  (either NIL, or from a CONST declaration, or
                  from an enumeration type),
             +    a set denotation whose elements, if present,
                  are ConstExpressions,
             +    a call of ABS, CAP or ODD with a parameter
                  which is a ConstExpression,
             +    a call of SIZE, MIN or MAX,
             +    a type conversion of the form:
                       typename(ConstExpression)
                  [see WG102 under VAL in $10.2].

WG088:  Numeric literals and constant identifiers are of the types ZZ
        and RR as defined in the paper "Expressions in Modula-2" [1].
        Consequently, a literal which is potentially of type LONGCARD
        does not have a different denotation from one which is
        potentially of type CARDINAL. [Such literals are actually of
        type ZZ.]

WG126:  As a result of WG099, it is possible to specify explicitly the
        type of a constant expression as illustrated by the following
        example:
             TYPE  OneInTen = [ 1 .. 10 ] ;
             CONST IntegerOne = INTEGER(1);
                   CardinalOne = CARDINAL(1);
                   OneInTenOne = OneInTen(1);

WG015:  The element of a set literal must be a ConstExpression if the
        set literal is a part of a ConstExpression.  The element of a
        set literal can be an Expression if the set literal is a part
        of an Expression.


6.6. Set types

WG131:  It was agreed that the Standard be worded so that an
        implementation must provide SET OF CHAR.

WG034:  It was agreed that if a program uses BITSET then BITSET must
        be imported from SYSTEM.  [See also WG074 in $8.2.]

WG035:  It was agreed that the constants N and W are to be exported
        from SYSTEM.  However, more meaningful names are to be used.

WG132:  It was agreed that a BITSET value maps onto the bits in one
        word.  It was also agreed that the underlying representation
        of a value which is of a set type other than BITSET is not to
        be defined.






                              - 3 -


6.8. Procedure types

WG089:  It was agreed that:
        +    NIL is compatible with an object which is of a procedure
             type;
        +    tests of (in)equality can be used between objects which
             are of a procedure type;
        +    there should be provision for procedure constants.



8. Expressions

WG041:  It was agreed that operands of an expression will be evaluated
        from left to right.



8.1. Operands

WG073:  Although a function procedure may return a value which is of a
        PROCEDURE, POINTER, RECORD or ARRAY type (see WG061 in $10),
        it was agreed that these results cannot be "applied",
        "dereferenced", "selected" or "indexed".



8.2. Operators

WG074:  It was agreed that the type preceding a set expression is no
        longer optional; so there is no longer a default to the type
        BITSET.  [See also WG034 in $6.6.]



8.2.1. Arithmetic operators

WG080:  It was agreed that out-of-range errors that occur during
        expression evaluation will yield an 'exception'.  For example:
        if there is a cardinal expression and its result is positive,
        but an intermediate result is negative, then an 'exception'
        will occur.



9.1. Assignments

WG050:  It was agreed that the right hand side of an assignment is to
        be evaluated before the left hand side.



9.2. Procedure calls

WG051:  It was agreed that the parameters of a procedure call are to
        be "evaluated" from left to right.







                              - 4 -


9.5. Case statements

WG056:  There should be an explicit statement that it is an
        'exception' if the selecting expression of a CASE statement is
        not found as a label, and there is no ELSE clause.  The
        definition could be modelled on PS 6.8.3.5, with minor
        modifications included for Modula-2's ELSE clause.



9.8. For statements

WG003:  It was agreed that PS 6.8.3.9 would be used as a starting
        point for the specification of FOR statements.



10. Procedure declarations

WG061:  It was agreed that a function procedure may return a value of
        any type.  Wirth has said that the restriction on function
        result types in PIM was an implementation restriction of his
        compilers:  the language itself has no restriction.

WG113:  It was agreed that FORWARD is not to be made part of the
        language.



10.1. Formal parameters

WG114:  It was agreed that the types of a formal VAR-parameter and
        that of its corresponding actual parameter must be identical
        (i.e. not merely compatible).  This rule may be relaxed when
        the formal parameter is of type WORD or ADDRESS.



10.2. Standard procedures

ABS, CAP, and ODD

WG075:  The agreed definitions for the above functions appear in the
        paper "Expressions in Modula-2" [1].

ORD, CHR, FLOAT and TRUNC

WG115:  The function procedures ORD, CHR, FLOAT and TRUNC are to be
        removed from the language.  Calls of these functions can be
        replaced as follows:
             ORD(value) can now be done by CARDINAL(value)
             CHR(value) can now be done by CHAR(value)
             FLOAT(value) can now be done by REAL(value)
             TRUNC(value) can now be done by CARDINAL(value - 0.5)
        For brief details of the use of a typename to coerce a value
        into some other type, see WG102 under VAL in $10.2.  For other
        details, see the paper "Type Conversions in Modula-2" [2].






                              - 5 -


HIGH

WG116:  It was agreed that the parameter to HIGH must be a variable
        that is specified as an open array parameter.  Thus, HIGH
        always delivers a result of type CARDINAL.  MAX applied to the
        index type of an array can be used for an array which is not
        an open array parameter.

WG117:  It was agreed that when a multi-dimensional open array
        parameter is passed to HIGH, HIGH delivers the high index
        bound of the first dimension of the array.


MAX and MIN

WG118:  It was agreed that the standard functions MIN and MAX take any
        'ordinal type' as a parameter.  They return the type's minimum
        and maximum values.  Consequently, if T is a subrange type,
        then MIN(T) and MAX(T) yield the lower and upper bounds of the
        subrange.  Note that MIN and MAX cannot be applied to the type
        REAL.  However, there will be some other mechanism to deliver
        the various characteristics of the type REAL.


SIZE and TSIZE

WG119:  I believe that no firm decision was reached as to whether the
        parameter passed to SIZE has to be a type or a variable or
        either.  Similarly, for TSIZE.  However, it was agreed that
        both SIZE and TSIZE should return 'storage units' where the
        size of a storage unit depends on the implementation.  It was
        also agreed that BitsInAStorageUnit is a constant identifier
        that is required to be exported from the module SYSTEM.


VAL

WG120:  It was agreed that SYSTEM would contain a function procedure
        called CAST which would do unchecked type transfers.
        So, given:
             VAR  v1:t1;  v2:t2;
        the call of CAST in:
             v2:= CAST(t2, v1);
        would return the value v1 interpreted as if it were of
        type t2.  For full details, see the paper "Type Conversions in
        Modula-2" [2].

WG102:  It was agreed that:
             typename(expression)
        would be used for type conversions.  [Such conversions are
        "safe" - they are sometimes called "coercions".]
        The restrictions on "typename" and the type of "expression"
        are defined in the paper "Type Conversions in Modula-2" [2].

WG121:  Because of the construct provided in WG102, it was agreed to
        remove VAL from the language.







                              - 6 -


DEC and INC

WG122:  It was agreed that:
        +    the form of DEC with two parameters is removed from the
             language;
        +    the parameter to DEC and INC must be a value which is of
             some 'ordinal type';
        +    both DEC applied to the first value of a type and INC
             applied to the last value of a type cause an 'exception'.

NEW and DISPOSE

WG085:  It was agreed to adopt the position adopted by the 3rd edition
        of PIM for NEW and DISPOSE, i.e., they are no longer part of
        the standard Modula-2 environment.  This is because the fact
        that they magically led to calls of ALLOCATE and DEALLOCATE is
        considered undesirable.





11. Modules

WG069:  It was agreed to follow Wirth's latest ideas about the scope
        of standard identifiers which are as follows:
             The standard identifiers can be considered as being
             defined in a universe.  If an identifier is not found
             within a program according to the scope rules, then that
             universe is searched as a last resort.  Note that this
             allows any standard identifier to be redeclared as a
             fresh identifier anywhere.
        This is in some ways similar to Pascal.  It is assumed that in
        the above definition, the word "program" should read "module".





14. Compilation units

WG109:  It was agreed that it is invalid to use the procedure heading:
             PROCEDURE p(i:INTEGER);
        in a definition module if the procedure is declared as:
             PROCEDURE p(j:INTEGER);
        in the implementation module: the same name has to be used for
        the two occurrences of the formal parameter.  This attempts to
        ensure that the two formal parameter lists correctly
        correspond, especially when there are two consecutive
        parameters of the same type.

WG084:  Wirth's proposal ("Revision 2.1") to discard the export list
        of a definition module is not to be adopted:  M2WG has agreed
        to retain the original syntax and semantics, i.e., objects
        which are to be exported from a definition module have to be
        listed in an export list.







                              - 7 -


WG110:  It was agreed that:
        +    an opaque type must be declared as a pointer type in the
             implementation module;
        +    an object which is of an opaque type may not be
             dereferenced in a client module.
        It was also agreed that:
        +    assignment between objects of an opaque type is legal
        +    comparison for (in)equality is legal for objects of an
             opaque type
        within a client module (as well as in the implementation
        module).  Assignment is needed to be legal as it implicitly
        takes place when a variable of an opaque type is passed as a
        value parameter to a procedure within a client module.



REFERENCES

1.  "Expressions in Modula-2", Brian Wichmann, "MODUS Quarterly"
    Issue 3, pp. 35-42.

2.  "Type Conversions in Modula-2", Brian Wichmann, "MODUS Quarterly"
    Issue 6.

3.  "All About Strings", Barry Cornelius, "MODUS Quarterly" Issue 6.



ELECTRONIC MAIL ADDRESSES

Any comments on these proposals can be sent to me at any of the
following electronic mail addresses:
     Barry_Cornelius%mts.durham.ac.uk@UCL-CS.ARPA
     Barry_Cornelius@uk.ac.durham.mts
     bjc@uk.ac.nott.cs