Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!mcvax!ukc!reading!brueer!johnl From: johnl@ee.brunel.ac.uk (John Lancaster) Newsgroups: comp.lang.modula2 Subject: Modula-2 standard Message-ID: <424@brueer.ee.brunel.ac.uk> Date: Tue, 2-Dec-86 07:55:24 EST Article-I.D.: brueer.424 Posted: Tue Dec 2 07:55:24 1986 Date-Received: Fri, 5-Dec-86 05:44:46 EST Organization: Dept of EE & E, Brunel University, Uxbridge, U.K. Lines: 192 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