some steps towards a better pascal

Yournal of Computer Languages, Vol. 1. pp. 277-286 Pergamon Press, 1976. Printed in Northern Ireland

SOME STEPS TOWARDS A BETTER PASCAL

BRUCE KNOBE

Intermetrics, Inc. 701 Concord Avenue, Cambridge, MA 02138, U.S.A.

and

GIDEON YUVAL Computer Science Department, The Hebrew University of Jerusalem, Jerusalem, Israel

(Received 12 June 1975; in revised form 21 October 1975)

Almract----Some changes in PASCAL are suggested, in line with its original aims. The suggested changes should broaden its range of application as well as improving its attractiveness to its current market.

Pascal Constant declarations Open procexlures Source listings Indenting

1. INTRODUCTION

THERE are several languages which have tried to supersede ALGOL-60 and FORTRAN IV. Possibly because it has a well-defined realistic goal, PASCAL [1, 2] seems to be succeeding where all other widely distributed attempts have failed. PASCAL was designed for teaching students. It is a language that can be completely mastered by a first year student and should serve handsomely in most undergraduate and many graduate courses. It would perhaps be nice to build PASCAL into a nested set of languages, some more powerful (for advanced users) and some less powerful (for the beginning student) than the current one; however, we address ourselves only to the problem of improving PASCAL at its current level. The current PASCAL has examples of many programming language concepts in a useful but limited form. We consider this a wise pedagogical approach and continue in this vein; for instance, we suggest adding the ability to define infix operators, but we restrict this facility so that it is not prohibitively expensive. We feel that important elements of the design of the language are its error detection capability and its ability to provide readable listings. It should be pointed out that a good compiler will detect an error at the first point where the program has no legal continuation; a good language design will keep this point very close to the point where the error occurred. A good programmer will write programs with a clear control structure; a good language design will provide a clear display of the control structure on the printed page.

PASCAL has already seen wide distribution and so one might argue that only upwards compatible changes should be made. We feel that this attitude is part of the reason we are still using fifteen and twenty year old programming languages. Since PASCAL is intended primarily as an educational tool, the number of important long-lived PASCAL programs is small. Since PASCAL is the first fairly successful language of its kind, the freezing of the most important aspects of the language before there has been a chance for substantial feed- back seems a very bad idea. We consider a change compatible if it is close enough to the original PASCAL that the transformation to the new syntax (or semantics) is a trivial, automatable project. All the changes we suggest here are compatible. There has been considerable critical comment on PASCAL, the most notable being that of Haberman [3].

1 277

278 BRUCE KNOaE and GIDEON YUVAL

These criticisms must ultimately be dealt with and this will undoubtedly engender some additional non-compatible changes. On the other hand, specifying a complete language and developing a viable implementation of it is a great deal of work. We would like to get the maximum benefit from this effort before moving on to the next, in the never ending chain of better languages; thus, we feel that the compatible changes to close languages should be explored first.

PASCAL was designed by the lazy man's philosophy "if it's hard to implement, it's a bad idea". This helps not only the implementer, but also leads to a clean, unfrilly language which lends itself to meaningful compile and run-time diagnostics. Following this approach, we have avoided suggesting changes that are difficult to understand or to implement. In most of the cases we have a fair idea of their implementation difficulty, having either implemented or at least analyzed a complete implementation as an addition to the ETH PASCAL implementation on the CDC 6000 machines. In all cases, we are sure that the ideas are implementable in a purely one pass compiler style.

2. PROGRAM READABILITY We consider the readability of the program to be of paramount importance. Thus we

want to enable and encourage the programmer (1) to use mnemonics whenever possible; (2) to write procedures which are short enough to be comprehended (certainly short enough so that the whole procedure can be seen at one time); (3) to write programs whose indentation structure illuminates the control structure.

We never want the programmer to be put in the position of affecting a tradeoff between good programming style and efficient programming. Many of our proposals are rather minor modifications or additions to PASCAL. Their aim is not to increase PASCAL's power to compute but rather to increase PASCAL's power to communicate (especially with oneself) and consequently its usefulness in an educational environment.

2.1 Constant declarations

Good programming style demands that constants be given mnemonic names and that these names, rather than the constant denotations, appear in the central part of the program. This produces a more flexible and more readable program. The programmer must be given the assurance that his constants can not be accidentally changed and that the compiled code is no less efficient as a result of using such names. To meet these demands PAS- CAL provides a CONSTant declaration. The current CONST declaration is too weak in two important respects:

(1) It does not allow for giving a name to an expression involving constants. Thus,

CONSTn = 3; twon = 2 * n ;

is not legal and must be written as

CONST n = 3; twon = 6;

The second line is clearly inferior to the first. We suggest that anywhere that a constant is required (i.e. in CONST and ARRAY declarations), an expression containing constants be allowed. Since most compilers (including the ETH PASCAL compiler) already contain optimizing code to evaluate expressions with constant operands at compile time, the additional effort necessary to allow expressions in the CONST declaration is negligible. We would expect the expressions to be composed only of built-in operators and operands whose values are already known constants.

Some steps towards a better PASCAL 279

(2) It only allows defining constants of simple type. It is impossible to define constant RECORDs or ARRAYs. As computer programming moves more and more in the direc- tion of computer science, we see an ever increasing usage of table driven programs. Thus, we want to encourage students to define tables which drive their programs. We want these tables deelareable as constants for several reasons:

(a) The declaration and definition of the table can then appear in the proper scope rather than as a global. The current practise of making such tables global is en- gendered by the necessity of eliminating the multiple execution of initialization code.

(b) The compiler can guranatee that no assignments are made to the tables. A non- constant constant is one of the hardest bugs to find.

(c) A large savings in space can be realized by eliminating the initialization code. (d) The compiler can produce code which is more efficient in both space and time if it

knows that a structure's contents are invariant for all time. For instance, the ETH compiler, whenever possible, generates an immediate instruction rather than a fetch.

(e) The intent of a program is certainly clearer if it contains a large declaration of constants rather than a large collection of assignments.

The utility of this facility may be judged by the use of the VALUE declaration, which existed in the first ETH implementation although not in the report (see [4] for a description of the implemented language). Although the VALUE declaration implies none of the checks we suggest and is rather clumsy to use, it was nonetheless used a great deal in the ETH compiler itself.

We suggest adding this facility to the language by broadening the definition of (constant definition)from:

(constant definition) :: = (identifier)= (constant) to:

(constant definition) :: = (identifier) = (constant expression) (identifier) = (type) ((constant list))

(constant list) :: = (constant expression) {, (constant expression)}*

Where (constant list) contains as many (constant expression)s as are necessary to fill exactly something of type (type). The order of this list is, of course, important. For records, the order is the order of declaration; for arrays, a two dimensional array is an array of rows; etc.

This facility could be used to declare

CONST i = complex (0, 1);

and then write readable, efficient, complex arithmetic expressions.

3. VARIABLE DIMENSIONS

When describing PASCAL to any user of ALGOL or FORTRAN, the first (and only unanswerable) complaint we get is that all array bounds must be compile-time constants. The existence of manifest constants means that a large number of array bounds can be changed by changing a few CONSTant declarations; nonetheless the programmer is in a worse position than he was in FORTRAN II; at least in FORTRAN he could cheat. We would like to see arrays with the generality of ALGOL-60 arrays, but it is likely that the problem of allocating storage for variable size arrays will introduce inefficiencies in procedure entry and in array accessing. We therefore suggest a compromise at FORTRAN

280 BgucE KNOBE and GrDEON YUVAL

IV style array allocation with a cleaner notation; that is, we insist that the size of an array must be a known, compile-time constant in the procedure in which it is allocated, but not necessarily in procedures to which the array is passed.

We suggest adding the facility of variable dimensions to the language by broadening the definition of the formal parameter section to include the alternative

BOUND (parameter group).

A name declared as a BOUND must appear in the declaration of at least one formal parameter and may also appear in the statement part of the procedure anywhere that a constant may appear. The semantics of this construct are that the compiler will generate code at the point of call to pass the correct value to the subroutine, and code in the subroutine to use the value passed. Since the compiler, which can be trusted not to lie, is passing this information; all run-time checks can be made with complete reliability; full type checking of formal and actual parameters can still be done on the subscripts; useful, con- cisely called functions of arrays can be written. If a BOUND appears in more than one ARRAY parameter, the compiler will check at compile time if possible and at run time when necessary, that no conflicts arise.

Using this notation we could write the fairly standard-looking matrix multiplication procedure:

PROCEDURE matmpy (BOUND d, m, n : INTEGER; a: ARRAY [1..d, 1..m] OF REAL; b: ARRAY [I . .m, 1..n] OF REAL;

c: ARRAY [1..d, 1..n] OF REAL); VAR VAR i,j, k : INTEGER; BEGIN

FOR i := 1 TO d DO FOR k :---- 1 TO n DO

BEGIN e[i, k] : = 0; F O R j := 1 TO m DO

c[i, k] := c[i, k] -b a[i,j] * b[j, k] END

END;

Note that a call to this routine would have the unusually brief form

matmpy (x, y, z)

regardless of the dimensions of x, y, and z. Our complaint against PASCAL is that it has no capability for writing the procedure regardless of the syntax.

The BOUND concept is equivalent in power to the ALGOL-68 [5] UPB and LWB functions but seems more pleasant to use and is easier to implement; furthermore, a lot of the required checking can be done at compile time. It should also be pointed out that UPB and LWB are rather nasty functions as their argument can be any army.

3.1 Function types and infix operators PASCAL functions cannot return structured values. This means that programs as

simple as matrix multiplication or dictionary lookup must operate using side effects.


Functions which return structured values are a very valuable facility for eliminating side effects. This is a practice we want to encourage in general and is an essential element for any truly modular program. Execution of such functions will often entail the overhead of copying the result into a lower place on the stack; however, this is a trade-off decision that the user can make (copying elements of type complex, for instance, would not be very expensive). The normal place to return function values is on the top of the run-time stack. In the ETH implementation, the registers are used as an extension of the stack for holding temporaries and function values. Since the compiler knows the result type at compile- time, old-style functions can still return their results in the efficient old-style, while new style functions can return their values on top of the stack.

In classical PASCAL, a programmer can write a procedure, plus, to add two structured variables together leaving the result in a third structure. Using this procedure, he could then set d to the sum of a, b, and c by declaring and using an intermediate structure, inter, with the code:

plus (a, b, inter); plus (inter, c, cO.

Once functions can return structures as values, a function plus could be written and the same computation could now be specified without declaring inter with the somewhat clearer code:

d : = plus (plus (a, b), c). No one can deny, however, that

d : = a q - b q - c , is the most desirable notation. PASCAL has a set of predefined infix operators which cannot be modified or extended by a source program. The very general infix operators of ALGOL-68 seem prohibitively expensive to implement, but we feel a limited facility would prove worthwhile in providing non-trivial examples of the concept of extensible languages and of building hierarchial programs using levels of abstraction. We propose allowing the user to define the operators -t-, --, *, / , MOD, DIV, a, v, = , ~ , < , > , > , < , and IN for those operand pairs where they are not already defined. We would use exactly the same syntax as for function declarations, simply replacing the keyword FUNCTION with the new keyword BINARYOP. Given that functions can return structured values, the addition of this facility is a trivial modification of the compiler.

When using this facility we could define the BINARYOP plus of arguments of types bee and tee. a : = b q- c is then semantically equivalent to a : = plus (b, c). Note that the appropriate BINARYOP is determined by both the operator and the types of the operands, no type conversions are done.

4. FOR STATEMENTS The net effect of many, perhaps most, well-structures FOR statements is independent of

the order in which the control variable moves through the (for list). The classical style FOR statement requires the programmer to specify an order whether or not he cares. We propose extending the FOR statement to allow expression of the inherent indeterminacy. Specifically, we suggest adding to

(for statement) : : = FOR (control variable) :---- (for list) DO (statement)

the additional alternative IFOR (control variable) IN (for set) DO (statement)

282 BRUCE KNOBE and GIDEON YUVAL

where

(for set) : := (simple type)](set)l(set-type variable).

Hoare [6] makes a similar suggestion. Given this construction we can write:

FOR c IN funnychars DO

rather than the more verbose, less clear, machine dependent: FORe := EOLTO ------;----- DO

IF c IN funnychars THEN

This is not in any way a contrived example, but rather exactly the kind of program we expect PASCAL users to be writing. There is no better way of doing this in current PASCAL.

In many places where this construct is applicable it is superior to the classical FOR statement because: (a) It allows a clear, concise statement of what is desired rather than a verbose statement containing unintended but syntactically required detail. This is parti- cularly important when trying to teach students to think and write at a high level and then fill in necessary details later; (b) It eliminates some of the machine dependency when deal- ing with type CHAR; (c) It allows the programmer to add items to or delete items from a scalar type without examining every reference to that type. (d) It allows a debugging and]or student compiler, if so requested, to randomize the order of execution, thereby enabling experimental verification of the assertion that the code is order independent. This facility exists in the TOPPS [7] language; (e) It allows an optimizing compiler to optimize. That is, since the compiled code need only have the same effect as the sequential execution of the FOR statement once for each value of the control variable, a clever compiler can do several such executions in parallel. This can have dramatic consequences on many popular com- puters.

Given the F O R . . . I N . . . construct, it then makes sense to introduce unordered (scalar types); that is, (scalar types) for which < , > , SUCC, PRED, and the classical FOR are undefined. Beyond the obvious advantage of allowing more precise statements, unordered types also introduce the possibility for considerably more compile and run-time checks than the situation where all types have implicit orderings. In particular, the use of < , > , SUCC PRED, or the classical FOR on unordered scalar types is an error detectable at compile time.

4.1 In-line code The use of procedures should be encouraged as much as possible. On the other hand,

the overhead involved in procedure call and return may be considerable. This problem becomes even more acute in PASCAL since the natural translation of an ALGOL-60 block is a parameterless procedure in PASCAL. Thus we would like to separate the notational convention of procedure call from the implementation technique of closed subroutine. We do this by introducing a new keyword. By writing OPEN before FUNCTION or PROCEDURE, the user indicates that it would be more efficient to insert the actual


procedure (open subroutine) rather than a calling sequence (closed subroutine), each time the procedure's name appears. An implementer may, of course, choose to regard OPEN as a null word word thereby simplifying the compiler and producing less efficient code.

It is possible that the normal parameter passing may sometimes have to be simulated for open procedures; however, the substantial procedure entry and exit overhead can al- ways be eliminated and in many cases, especially with constant parameters, the entire parameter passing can be eliminated. Example:

OPEN PROCEDURE nextch{get next character from blocked file}; BEGIN

IF pointer ~ maxpointer THEN readblock; newchar :---- buffer [pointer]; pointer := pointer + 1 ;

END;

In this procedure, the procedure entry and exit code would ordinarily take more time than the execution of the procedure body. Several calls to such a procedure are likely to occur in the critical section of a compiler. The OPEN facility allows us to maintain the clarity and modifiability of the procedure call, and still achieve the efficiency of in-line code.

5. OUTPUT

The function WRITELN is part of the language. Thus, a programmer who knows about carriage control characters can produce any output produceable on the printer he is using. We propose adding three more such functions:

WRITENEWL=WRITELN followed by the single space carriage control;

WRITENEWP=WRITELN followed by the page eject carriage control;

WRITESAML=WRITELN followed by the no space carriage control.

Given these functions, the student need not learn about the carriage control characters un- til and unless his instructor finds it adviseable; furthermore, PASCAL programs become less machine dependent, as the implementation at a given site defines the appropriate constants for that site.

6. PRAGMATICS It is now customary to define a language in a fairly formal document which attempts to

specify the syntax of the language and the semantics of all well formed programs. This document usually is very far from a total specification for a translator, the rest of the details being left to the discretion of the implementer.

The implementer rarely has the love for or the comprehension of the principles of language design (especially designing languages for novices) that the designer does; furthermore, the implementer rarely expects to write many programs in the language he is im- plementing.t These considerations imply that the designer must try to specify, or at least

t Although the ETH PASCAL compiler is written in PASCAL, it is not a well written PASCAL program, it is not representative of PASCAL proprams, and it was not written by the kind of people PASCAL is intended for, furthermore, the specification of the PASCAL language does not specify that the complier must be implemented in PASCAL.

284 BRUCE KNOaE and GIDEON YUVAL

outline, all areas which will impact on the user. The elements of the language which will have significant impact vary from one user community to the next. It is the designer's responsibility to decide which considerations are important and which he may leave in the area where the implementer can use his own judgement. We have mixed feelings about the appropriate point in the language design/implementation spectrum to specify this material. On the one hand, we would not want to say it is as much part of the language as the list of keywords; on the other hand, we would like to say that an implementation which was missing these facilities was only a partial implementation. If we look at the problem from the viewpoint of a user's manual, we would say that the inclusion of this material should simply appear in the normal course of the text (not in a list of special features) while the exclusion of it should be explicitly confessed.

7. C O M P I L E R D I R E C T I V E S

It is frequently desireable to be able to give information to the compiler which will have no effect on the semantics of a correct program. Such information might include: commands to control the listing; commands to turn the compilation of run-time checks on or off; optimization information; etc. Although the PASCAL language contains no such facility, the ETH compiler does.

The ETH compiler employs the idea of pseudo-comments; that is, something which is syntactically a comment but which might not be ignored by the compiler. The pseudo- comment idea has several advantages. Principal among them are:

(1) an implementation which does not include all possible compiler directives will automatically treat the ones it doesn't understand as comments. Thus a program which is correct will run under several implementations, even though under some implementations various non-critical factors may be better than under others;

(2) it guarantees that there are no conflicts between statements of the language and directives to the compiler. Since we expect these directives to be terse commands rather than readable (somewhat redundant) programming language code, this separation has considerable merit.

We would like to see the following compiler directives added to the existing ones: (i) cause a page eject in the program listing; (ii) turn the printing of the program listing

on or off; (iii) turn automatic indenting of the program listing on or off; (iv) turn the accumulation of references for a cross-reference table on or off. As the language and its compilers grow in sophistication, we might also add directives which:

(i) limit the compiler to some proper subset of the language; (ii) announce that some portion of code ought or ought not to be optimized; (iii) pass to the compiler optimization information.

8. L I S T I N G

A program is readable if and only if the listing of the program is readable; thus a considerable amount of attention must be paid to providing both automatic and programmer controllable listing facilities.

Everyone agrees that indenting the listing to reflect the structure of the program makes a major contribution to the program's readability. We agree with project SUE [8] that the compiler should do the indenting, perhaps with an option to turn off the indenting. We feel that it is important that the compiler take the responsibility of doing the indenting


because: (1) The compiler can guarantee that the indenting reflects the actual structure, not the intended structure; (2) A small change in the program can imply a large change in the indentation structure, asking the programmer to rekeypunch his whole program several times is dearly ridiculous; furthermore, reformatting the cards automatically is incom- patible with maintaining the source file in an updateable format.

The printer line is typically wider than the input medium; thus the compiler has more room to indent than the programmer.

It is difficult for inexperienced keypunchers to type entire indented programs. It is a considerable annoyance for anybody making a small number of changes to a large existing text.

It has been suggested that indented listings, cross reference listings, and other similar facilities, can be provided by separate user supplied programs. Since every computer center already has a listing utility, this argument applies even more strongly to eliminating the listing from the compiler.

Although automatic indentation takes a considerable effort (ca. 200 statements in the ETH compiler), we feel it is effort well worthexpending. The compile-time cost due to indenting is treated in [9].

When handling large programs, it is vital to be able to turn the listing on or off for selected parts of the program. Adding a pseudo-comment to control this takes a negligible effort.

9. CROSS REFERENCE LISTING

This feature appears in almost all assemblers and in some compilers. At least in this aspect, the higher-level languages have a lower-level implementation. This feature can be very expensive in terms of compilation time and very valuable in terms of programmer time. We would therefore implement it under control of a compiler directive, initially off. The compiler would accumulate references only when directed to do so. It would sort and print the accumulated references, only if the accumulation switch was on at the end of the program.

No one doubts that locality of variable reference is a good thing. Programs as people write, however, (e.g. the ETH PASCAL compiler) contain many references to global variables [10]. Given that no OWN variables exist, this is sometimes inescapeable. Also, references to globally defined TYPEs are usually a good thing. Therefore, cross reference listings cannot be totally replaced by good programming practice.

10. CONCLUSION

P~CAL is the first reasonably successful successor to ALGOL 60. The language has been available for use for several years now and in that time several weaknesses in the language have been found. On the other hand, the increasing popularity of the language and the increasing availability and quality of compilers seems to mitigate for perturbations of the existing design in an evolutionary manner rather than an ALC, OL 68 style break with all previous tradition. We have presented a collection of language features which we believe are consistent with this evolutionary approach. We believe that these features would sub- stantially improve Pascal's position in the market place and also enhance its attraction for its current following. We know that these features can easily be added to the ETH implementation for the CDC 6000 series and expect that there would be little difficulty in adding them to any other implementation.

286 BRUCE KNOBE and GIDEON YUVAL

About the Author--BRUCE S. KNOaF. received the B.S. degree from M.I.T. in 1964, the M.S. degree from the University of Illinois in 1966, and the Ph.D. from New York University in 1972.

Dr. Knobe has held teaching positions at New York University, Colorado State University, and The Hebrew University of Jerusalem. He is currently working for Intermetrics, Inc., doing compiler design and development for NASA. Dr. Knobe has published numerous papers and reports in the area of language design and the practical aspects of compiler construction.

About the Author---Gn3~ON YUVAL received the B.S. and M.S. degrees in Physics from the Heb- rew University of Jerusalem and then the Ph.D. degree in Physics from Cambridge University in 1970. He is currently visiting Carnegie-Mellon University on leave from the Hebrew Univer- sity of Jerusalem.

Dr. Yuval has published several papers in theoretical physics but his interest have now turned wholly to computer science. His contributions to the computing literature run the gamut from tricks for making a CDC 6000 do what is desired to analysis of algorithms.

Acknowledgement--We would like to thank Professor C. A. R. Hoare for his very helpful criticism of an earlier draft of this paper.

R E F E R E N C E S 1. N. Wirth, The programming language PASCAL. Acta Informatica 1, 35 (1971). 2. K. Jensen and N. Wirth, PASCAL---User Manual and Report, Springer, Berlin (1974). 3. A. N. Haberman, Critical comments on the programming language PASCAL. ,4cta Informatica 3, 47

(1973). 4. W. F. Burger and D. Lynch, PASCAL Manual. Computer Center of the State University of New York

at Buffalo, Buffalo (1973). 5. C. H. Lindsay and S. G. van der Menlen, Informal Introduction to ALGOL-68. North-Holland Publishing

Company, Amsterdam (1971). 6. C. A. R. Hoare, A note on the FOR statement. BIT72, 334 (1972). 7. B. Czarnik and D. Tsichritzis, (Ed), A student project for an operating systems course. Technical Re-

port CSRG-29, Computer Systems Research Group, University of Toronto, Toronto, Canada (1973). 8. B. L. Clark and J. J. Homing, The system language for project SUE. SIGPLANNotices 6, 79 (1971). 9. B. S. Knobe and G. Yuval, Making a Compiler Indent (in preparation).

10. N. Wirth, On "PASCAL", code generation, and the CDC 6000 computer. STAN-CS-72-257, Com- puter Science Department, Stanford University, Stanford, CA, p. 28 (1972).

some steps towards a better pascal

Documents