🚀 go-pugleaf

                    Will Modula-2 be Successful?  NO!


I have  been using Modula-2 for some time and watching the efforts of the
BSI Modula-2 Working Group [1] to  standardize the  language.  Throughout
this period I have often asked myself:

    'Will Modula-2  be efficient/versatile  enough to  be a winner in
    the general programming language market place?'

In the form proposed by Wirth I feel the answer is no.   The  BSI Working
Group has  done much  to improve  the situation and I would like to thank
its members for their unpaid efforts.  They have formalised  the language
definition  and  introduced  extensions/changes  to  it  where necessary:
multi-dimension open arrays [2] and  co-routines  [3]  are  two examples.
However, there  are still  deficiencies.   Below I  highlight a number of
problems and propose solutions to them.


PROBLEM 1.  Structured Constants

At present structured constants  are implemented  by declaring  a  global
variable which  is initialized  at runtime  by code  in the  body of each
module.

There are two disadvantages to this approach:

1.  The "constant" is not safe because it is really a variable, hence the
    compiler cannot protect it from unintentional change.

2.  For  those  structures  whose  value  cannot  be  derived  by  simple
    computation, constants are duplicated in the  data and  code areas of
    the program.   This  can be  a high  overhead in memory-sensitive ROM
    based systems.

SOLUTION 1.  Allow for the declaration of structured constants (CONST) as
provided in the Turbo Pascal [4] dialect of Pascal.


PROBLEM 2.  Parameter types.

Consider the following two procedures:

PROCEDURE MatrixOp (Op1, Op2 : ARRAY OF WORD,
                    VAR Result : ARRAY OF WORD)

PROCEDURE Length (String : ARRAY OF CHAR) : CARDINAL

These procedures  have their  input parameters passed by value.  Although
this is a safe  method, the  time spent  creating a  local copy  of input
parameters can have a severe effect on execution speed.

Many programmers consider the above inefficient and work around it by the
unsafe  practice  of  declaring  structured  input  parameters  as  VARs.
Unfortunately in  the case  of the 'Length' procedure this causes another
problem, namely the following is not legal:

    Size := Length('Literal String')

SOLUTION 2. Add to the language  a new  formal parameter  PVAR (protected
variable).   The implementation  of a PVAR parameter is identical to that
of a VAR  parameter  except  that  compile-time  checks  protect  it from
modification within the procedure by not allowing assignment to it or its
use as a VAR parameter.

As an aside I would also like to be able to code
    Result := MatrixOP (Op1, Op2)

where the function is supplied with  a  pointer  to  Result  and directly
operated on  it rather  than creating  an internal result which is passed
out and assigned to Result.   Although  the  syntax  of  Pascal  could be
modified  to  accommodate  it,  it appears that Modula-2's syntax cannot.
Does anyone have any idea?


PROBLEM 3.  User exception handling.

There is  no  provision  in  Modula-2  for  the  programmer  to implement
exception  handling.    This  is  primarily  due  to  the  absence  of an
equivalent to the Pascal  construct "GOTO  Label_InOuterBlock".   The BSI
proposed  IO  library  [5]  works  around  this  shortcoming by predicate
pretesting, i.e. testing if an operation  can be  performed before trying
to do  it.   Although such  an approach  has merit  it is not universally
applicable.

SOLUTION 3.    Allow  for  user-written  exception  handlers  as  in ADA.
Borland's [6]  have proposed a possible Modula-2 implementation.


PROBLEM 4.  BITSET size and syntax.

The  data  type  BITSET  provides  a  simple mechanism for bit addressing
(thereby allowing the crippled data type SET to be replaced  by something
more useful) and performing logical operations on word wide variables.

The deficiencies  of BITSET  become apparent on a machine with a variable
word size addressing architecture  like the  8086 &  68000 microprocessor
families.    Direct  bit-twiddling  of  the  hardware  registers  on such
machines requires the language to support more than  one size  of BITSET.
For  the  68000  family  BITSETs  of  8, 16 & 32 elements (bits wide) are
required.

SOLUTION 4.   Introduce  a  new  type  construction,  which  needs  to be
imported from SYSTEM, with syntax of the form:

    RegBitMap = BITSET OF [TxOn,RxOn,NIL,NIL,Reset,NIL,NIL,Error]

The size  of the  memory 'word' being addressed is given by the number of
elements in the set.  Allowing the elements  of the  set to  belong to an
enumerated  type  in  addition  to  a  CARDINAL  sub-range  brings to bit
addressing the same benefits it gives to variable (word) addressing.  The
reserved  word  NIL  is  used  as  a  padding (spacing) element, but also
indicates to the compiler those bits which should not be accessed.


PROBLEM 5.  Word subfields.

Consider a hardware device with the following bit allocation

    ---------------------------------
    |. . . .|* * * *|* * . .|. . . .|
    | | | | | | | | | | | | | | | | |
    ---------------------------------

where '.' are 1-bit flags
and   '*' is a 6-bit integer

To be efficient a  low-level module  which accesses  the integer subfield
should generate in-line code for bit shifting and sign extension.

SOLUTION  5.    Require  SYSTEM  to export Shift and SignExtend functions
which operate on all word sizes.

PROBLEM 6.  Low-level escape path.

When SYSTEM does not export a suitable low-level  facility the programmer
must resort  to calling  an assembly language module.  Such a solution is
unattractive because:

1.  Calling a module  to  execute  one  or  two  machine  instructions is
    inefficient.

2.  The  special  link  format  used  by  many of the currently available
    Modula-2 compilers cannot (easily) be linked with non-Modula-2 object
    files.

SOLUTION 6.  SYSTEM must export a "code insert" facility.


I have  presented above  a number of extensions to the currently proposed
BSI Modula-2 standard.  With the exception of  the BITSET  proposal their
adoption  would  not  invalidate  any  existing  code.    I feel they are
justified by the inability  of the  proposed language  to implement these
features with  (library) modules else they are justified by the resulting
increase in program reliability and efficiency they offer.

Although I welcome comment on my proposals I  feel that  the interests of
the community  are best served by submissions to the BSI Modula-2 Working
Group and encourage readers to do so.


REFERENCES:

1.  The Modula-2 Working Group of the  British Standards  Institution can
    be  contacted  via  Barry  Cornelius, Department of Computer Science,
    University of Durham, Durham, DH1 3LE, United Kingdom.
          Barry_Cornelius%mts.durham.ac.uk@UCL-CS.ARPA
          Barry_Cornelius@uk.ac.durham.mts
          bjc@uk.ac.nott.cs

2.  "BSI Accepted Change: Multi-dimensional open arrays",  Willy Steiger,
    "MODUS Quarterly" Issue 5, pp. 8-9.

3.  "Coroutines and Processes", Roger Henry, "BSI Modula-2 Working Group,
    Second Open Meeting", July 24th 1986.

4.  Turbo Pascal is a registered trademark of Borland International Inc.

5.  "Draft BSI  Standard  I/O  Library  for  Modula-2",  Susan Eisenbach,
    "MODUS Quarterly" Issue 5, pp. 15-18.

6.  "Proposal  for  a  standard  library  and  an Extension to Modula-2",
    Odersky,  Sollich  &  Weisert   of   Borland   International,  "MODUS
    Quarterly" Issue 4, pp. 13-25.


John Lancaster,
London, UK

johnl@uk.ac.brunel.ee
johnl%ee.brunel.ac.uk@ucl-cs.arpa