THE PROPOSED STANDARD FOR MODULA-2
----------------------------------

USUS members may be curious as to the state of the proposed standard for
Modula-2.

This "unofficial" note aims to give some idea of the rough state of the
language that is likely to be proposed in the next Draft of the Standard,
as agreed at the most recent meeting of WG13/SC22, held in July 1991 in
Tuebingen, Germany.

The note is (deliberately) imprecise, but should give you a feeling of the
surprises one may expect to see when the draft is published, probably later
this year.  In what follows I have focussed on the "added" features, rather
than the "clarifications", of which there are many (for example, exactly
what is meant by compatibility in various contexts).

Devotees of Modula-2 as it was originally described in PIM (Programming in
Modula-2, Wirth's textbook), where it was a rather "small" language, may be
surprised at some of what follows.  Indeed, the trend towards extending the
language desire for extensions is not shared by all of the Standards group,
and in particular not by the US members.

Comments, criticisms and queries will be welcomed.  You can e-mail them to
me, at either of the addresses:

      Pat.Terry@f4.n7104.z5.fidonet.org
or
      pdterry@m2xenix.psg.com

or, on FidoNet as Pat Terry of 5:7104/4.

You can also send comments to the chairman of the US TAG (Task Action
Group), Randy Bush, whose name will be familiar to aficionados of the
excellent old Volition Modula-2 and Oregon Software Modula-2
implementations.  Randy can be contacted by e-mail at

       randy@m2xenix.psg.com

or, by regular mail, at

       Pacific Systems Group,
       9501 SW Westhaven Drive
       PORTLAND
       OR 97225

Any errors and misleading statements in what follows are unintentional, and
are my responsibility; they should not reflect on the other members of the
group.

The draft of the proposed standard document runs to about 500 pages, and
there are still bits to be added to the text.  Much of this bulk is
attributable to the fact that the language is specified primarily using a
mathematical language "VDM-SL" (Vienna Definition Language - Specification
Language").  And part of the delay in standardizing Modula-2 has arisen
because VDM-SL is not yet standardized or stable either!

On to the changes:

New reserved words:
-------------------

    REM  FORWARD  PACKEDSET  EXCEPT   FINALLY   RETRY

/ and REM provide alternative ways of doing whole number division and
remaindering.  PACKEDSET is a way of specifying "packed" sets (that is,
bitsets), and EXCEPT, FINALLY and RETRY are there to deal with exception
handling and termination, probably the biggest and most contentious
additions to a once fairly simple language in this area.

New pervasive (standard identifiers):
-------------------------------------

    COMPLEX  CMPLX   ENTER   IM   INT   INTERRUPTIBLE  LEAVE
    LENGTH   LFLOAT  LONGCOMPLEX  PROT  PROTECTION     RE  UNINTERRUPTIBLE

These are discussed in more detail below.

New lexical elements:
---------------------

    (! and !)  as equivalents for [ and ]
    (: and :)  as equivalents for { and }
    @          as equivalent for ^ (pointer dereferencing)

These are all to handle non-ASCII machines.

    <* compiler directives *>  in <* brackets *>

This attempts to get away from comments that are not really comments and to
ensure portability to a greater extent than before.

    __Underlines_allowed_anywhere_____in_identifiers

This should be attractive to devotees of this style.

While the Committee has not gone so far as to introduce a STRING type (the
issue was discussed), some extra support for string operations has been
added.  For example

    +  may be used to concatenate string constants: "this" + " is fun"


New types:
----------

The new types COMPLEX and LONGCOMPLEX give possibility for doing complex
arithmetic very much as in FORTRAN.  Standard identifiers

        CMPLX(real, imaginary)    construct complex from real
        RE(complex)               extract real part
        IM(complex)               extract imaginary part

and a basic complex library has been proposed.

The type PROTECTION allows for more "portable" control over interrupts.
Five standard identifiers are introduced for this:

       function PROT()  returns current level of protection

       INTERRUPTIBLE, UNINTERRUPTIBLE  define two of the levels (an
             implementation may add others)

       procedures ENTER(protection)  and LEAVE(protection)  allow for
             bracketing statements to guard against interrupts

As already mentioned, there is a new type constructor.  The PACKEDSET
keyword allows for construction of sets required to be "packed" so that
each element is represented by one bit.  For example

        TYPE
          Permissions = PACKEDSET OF (mayOpen, mayClose, mayTryCinstead);

and the standard type BITSET is in this category:

        TYPE
          BITSET = PACKEDSET OF [0 .. SomeImplementationDefinedLimit];

Other sets are not required to be packed, and the upper limit on set size
may be considerably larger for "ordinary" sets than for "bitsets".

Other new pervasive identifiers have been added to clean up type
conversions:

     INT(real)             convert real to INTEGER
     LFLOAT(wholenumber)   convert wholenumber (INTEGER/CARDINAL) to
                           LONGREAL

Other conversion functions like this have also been "relaxed".  So, for
example,

     FLOAT(wholenumber)    convert wholenumber (INTEGER or CARDINAL) to REAL

The general purpose type converter, VAL, has been considerably relaxed.
Note that VAL does not cast or coerce, as it does in some present
implementations.

The last new pervasive is LENGTH:

     LENGTH(string)        returns length of its string parameter


Type Casting:
-------------

Type casting is now to be done as SYSTEM.CAST(TYPE, value), not TYPE(value)
as it was in PIM.  This is to ensure that the potentially non-portable use
of this feature is properly highlighted.  The TYPE(value) syntax is tp be
removed.


Various other fundamental changes:
----------------------------------

Various of these have been made.  Some of these would take too long to
explain in detail here:

The order of initialization of circularly importing modules is now defined.

Recursive procedure types are allowed (for example

       TYPE  RecProc = PROCEDURE (Real, RecProc)

Coroutines have been moved from SYSTEM to another system module, named
COROUTINES.  Several extra features have been added; and these are no
longer directly compatible with PIM.  The motivation is that interrupt
handling, in particular, on the PIM model was inadequate.

Multi-dimensional open array parameters are allowed.

A new set of rules for FOR statements and their control variables has been
formulated.  Basically, thou shalt define control variables locally and
thou shalt not alter them; this is explained more clearly in about 16 pages
of formal specification!

FORWARD declarations are allowed, and must be acceptable to multipass
compilers.

Termination and exception handling have been built into the language
through the keywords FINALLY and EXCEPT and RETRY, along with a supporting
system level module.  This is a very big change.  Some idea of the feature
can be gleamed from the following examples:

  IMPLEMENTATION MODULE Wotsit;

    IMPORT EXCEPTIONS (*system module*);

    VAR
      LocEx : EXCEPTIONS.EXCEPTION;

    PROCEDURE Action ();
      VAR
        Which : EXCEPTIONS.EXCEPTION;
      BEGIN
        Something;
        IF Wrong THEN EXCEPTIONS.RAISE(LocEx) END;
        SomethingElse
      EXCEPT
        HandleException;
      END Action;

    BEGIN (*Module body*)
      InitialisationCode;
    FINALLY
      TerminationCode
    EXCEPT
      HandleTheException
    END Wotsit.

Second example:

   FROM EXCEPTIONS IMPORT
     ExceptionValue, EXCEPTION, RAISEGENERALEXCEPTION;
   FROM LibModule IMPORT
     LibExceptionValue, LibException, Fly, ReplaceRubberBand;

   PROCEDURE KeepFlying();

     PROCEDURE TryFlying();
       BEGIN
         Fly
       EXCEPT
         IF LibExceptionValue() = BrokenRubberBand
         THEN
           ReplaceRubberBand;
           RETRY
         END
         (* Re RAISE exception *)
       END TryFlying;

     BEGIN
       (* Statements in normal execution *)
       TryFlying;
       (* ..... *)
     EXCEPT
       CASE ExceptionValue() OF
         | NotLanguageException:
             RAISEGENERALEXCEPTION("Unknown library exception")
         | IndexException
             (* Take recovery exception if possible *)
             RETRY
         (*  Other cases *)
         ELSE
           (* Re Raise exception *)
       END
   END KeepFlying;

Value constructors are allowed for arrays and records, as well as for sets:

     TYPE
       ArrayType = ARRAY [0 .. 10] OF REAL;
     VAR
       x : ArrayType;
     BEGIN
       (* lots of code *)
       x := ArrayType{5.3 BY 5, 6.7, 8.2*sqrt(y), 0.0 BY 3}

Full generality is allowed, which this simple example does not show.  In
particular, note that it is not intended just for constants or for variable
initialization.

The SYSTEM module typically is required to export

    LOC, BYTE, WORD, ADDRESS, MACHINEADDRESS (*types*)
    ADDADR, SUBADR, DIFFADR, ADDRESSVALUE (*ADDRESS manipulation*)
    SHIFT, ROTATE
    CAST (*type casting*)
    TSIZE, ADR (*old favorites*)

LOC is the "smallest addressable location" (typically a byte).
MACHINEADDRESS is for use in specifying absolute addresses in variable
declarations:

    VAR
      Screen [ MACHINEADDRESS {0B800H, 0H} ] : BigArray;


Library modules:
----------------

The modules of the "standard" library will be "optional" - however,
implementations that claim to be standard will not be allowed to have
modules of these names that do not conform exactly to the features and
semantics of the "standard" ones.  Note also that several of these will
make direct use of the exception handling features, and so will be rather
unlike anything seen up till this time.  Onlu the briefest of summaries can
be given here:


I/O Library
-----------

This is different in very many respects from all of the ones proposed
in earlier drafts of the Standard.  Indeed, every draft has seen virtually
a complete redesign on what has gone before.

   I/O operations (reading, writing)

     StdChans          10 procedures
     ProgramArgs        3 procedures
     IOTypes            1 type

     TextIO             8 procedures
     WholeIO            4 procedures
     RealIO             5 procedures
     LongIO             5 procedures
     RawIO              2 procedures
     IORes              1 procedure and 1 type

     The following are much the same, but for default channels

     STextIO            8 procedures
     SWholeIO           4 procedures
     SRealIO            5 procedures
     SLongIO            5 procedures
     SRawIO             2 procedures
     SIORes             1 procedure and 1 type

  Device modules (opening, closing, positioning)

     DevConsts          3 types and 7 constants
     StreamFile         3 procedures, 3 types and 5 constants
     SeqFile            7 procedures, 3 types and 5 constants
     RndFile           10 procedures, 5 types and 6 constants
     TermFile           3 procedures, 3 types and 5 constants

  Interfaces

     IOChan            17 procedures and 3 types
     IOLink             7 procedures and 17 types

Storage
-------

   Storage            5 procedures, 1 type and 2 constants

Concurrent processing
---------------------

   Processes         16 procedures and 5 types  (Not the PIM module)
   Semaphores         5 procedures and 1 type

String handling
---------------

   CharClass          6 procedures
   Strings           21 procedures and 3 types
   ConvTypes          2 types
   WholeConv          8 procedures
   RealConv           7 procedures
   LongConv           7 procedures
   WholeStr           4 procedures
   RealStr            5 procedures
   LongStr            5 procedures

System clock
------------

   SysClock           5 procedures and 8 types

Mathematics
-----------

   RealMath          12 procedures, 2 constants and 1 type
   LongMath          12 procedures, 2 constants and 1 type
   ComplexMath       15 procedures and 1 type and 3 constants
   LongComplexMath   15 procedures and 1 type and 3 constants
   LowReal           15 procedures and 15 constants
   LowLong           15 procedures and 15 constants
 
