R. S. Scowen

The definition of comments in programming languages

This paper examines the concept of comments in programming languages and answers the questions: Why are they needed? How are they defined and implemented in existing languages? What should be provided in future languages?

A standard syntactic metalanguage

The value of a syntactic metalanguage is well known to readers of SIGPLAN Notices. It is useful not only for the syntax of programming command languages, but whenever a formally defined syntax is required~ e.g. the format for references in scientific reports. A formal syntax definition has three distinct uses: it names the various syntactic parts (i.e. non-terminal symbols) of the language; * it shows which sequences of symbols are valid sentences of the language; * it shows the syntactic structure of any sentence of the language. A forthcoming British Standard [BSI 81] defines a new standard syntactic metalanguage. One advantage is that it can be typed on computer terminals and processed by computers. This article is a general guide and explains some of the background; for a precise specification, you must turn to the standard itself. A simple introduction for programmers [SCOW81] has also been written.

Some aids for program documentation

The documentation of computer programs can be considerably eased and standardized using the programs described in this paper. They are basically machine‐ and language‐independent, possess a simple structure, use one serial input and one output stream, and require no backing store. The code size for each program is a few thousand bytes and the time for running them is dominated by that needed for input and output. The programs are: 1 INDEX (gives an index of all identifiers used in a program). 2 POLISH (paginates a program listing so that the global structure is evident). 3 WATER (helps find misprints in computer‐readable reports). 4 UNDOC (creates a live program from its documented form).

Conformance testing of software

Abstract People who buy software want a guarantee that it works. When they cannot satisfy themselves, and do not wholly trust the programmer, it is natural to seek the help of a third party who will certify the software. So far, formal certification is available only for compilers. This paper discusses some of the theoretical problems and reviews existing compiler validation schemes. Finally there is a brief examination of other methods of quality assurance that might provide a better solution.

Writing algorithms in algol 60

This paper discusses the difficulties of writing procedures and programs in ALGOL 60 for general use. It also shows how the problems can be alleviated and overcome.

Seven sorts of programs

When computer scientists talk of debugging programs they mean detecting and removing the errors. This naturally encourages an over-simple view that a program is either right or wrong. This note suggests that there are at least seven degrees of correctness for a program. A simple Algol 60 program that calculates the average of up to ten numbers is used as an example.This note originally appeared as an appendix to a report on Compiler Validation published by NPL [SCOW80].

A survey of some text editors

Every computer system seems to have a different method of editing files. This survey considers the tasks, constraints and user interface for computer editors. Several editors are examined and reviewed. This paper also contains a glossary of some terms connected with editing and includes a reference to other surveys and bibliographies.

The programming language standards scene, ten years on Paper 13: Prolog

Abstract This paper, one of a simultaneously published set, describes the establishment in 1984 of the standards project for the programming language Prolog, and subsequent progress of the project, which at the end of 1993 is almost complete. This brief overview of the forthcoming standard concentrates on issues of general interest: for example, concepts such as unification and a user-defined syntax are being standardized for the first time. Their definitions can and should be re-used in the standard for any other language which includes these concepts.

The Predicate consult/1 — A Problem in Prolog Standardisation

The process of Prolog standardisation has disclosed many unexpected problems. One area currently under consideration is the definition of the predicate consult/1 which reads a file and loads the predicates defined there into the database. Although the definition of consult/l was initially simple, implementers have extended and changed its meaning and effect. This paper identifies the requirements for consult/l and poses several questions which must be answered in the standard.

Writing algorithms in ALGOL 60

1N7R0DUC710N 1t 15 much m0re d1ff1cu1t t0 pr0duce an a190r1thm f0r pu611cat10n 0r 9enera1 u5e 1n a 116rary 5y5tem than f0r 0ne • 5 0wn per50na1 need5. 7he rep0rt d15cu55e5 the d1ff1cu1t1e5, and w111 he1p pr09rammer5 wh0 are a1ready fam111ar w1th AL60L 60 t0 pr0duce 116rary 0r pu6115ha61e a190r1thm5. N0 attempt 15 made t0 teach the maj0r feature5 0f AL60L 60 51nce th15 15 a1ready amp1y c0vered 6y many text-600k5. 7he pr0pert1e5 re4u1red 0f a 116rary a190r1thm A per50na1 a190r1thm need 0n1y 6e 5uff1c1ent1y accurate f0r 1t5 a150 6e:-1 c0rrect 2 p0rta61e 3 1nte1119161e 4 r06u5t 5 eff1c1ent and eff1c1ent 1ntended purp05e, 6ut 1f 1t 15 t0 6e part 0f a 116rary 1t mu5t A1th0u9h c0rrectne55 15 0f param0unt 1mp0rtance 1t 15 5urpr151n9 h0w many pu6115hed a190r1thm5 fa11 t0 5tate exact1y what they d0 and the c1rcum5tance5 1n wh1ch they w0rk. Many a150 c0nta1n m15pr1nt5 0r 0ther err0r5. Even 1f an a190r1thm 15 c0rrect 1t w111 6e 0f 0n1y 10ca1 u5e un1e55 1t 15 p0rta61e, that 15 un1e55 1t can 6e tran5ferred fr0m 0ne c0mp11er and mach1ne t0 an0ther. Pr061em5 0f mach1ne accuracy, hardware repre5entat10n, 1an9ua9e 1eve1, c0mp11er var1at10n5, 1nput/0utput 0r 0f 0ther 116rary pr0cedure5 u5ed, aL1 make a190r1thm5 1e55 p0rta61e. H0wever, the pr061em5 can 1ar9e1Y 6e av01ded 1f they are 60rne 1n m1nd when de519n1n9 and wr1t1n9 the a190r1thm.