moss@cs.umass.edu (Eliot Moss) (07/27/90)
In the design of CLU we orginally had Algol/Pascal style control construct
syntax, such as "if <expr> then <stmt> else <stmt>" (i.e., without closing
keyword), so that one required a begin/end pair for a then or else action more
than one statement long. Even with single character abbreviations for
begin/end (we used "{" and "}") we felt this was a pain, and while a closing
bracket does mean a little more typing, it is leads to simpler program
modification, especially adding/deleting statements. Having a closing bracket
also resolves the syntactic ambiguity of the "dangling else" in "if .. then ..
if .. then .. else" (i.e., does the else go with the first or second then?). I
have also heard (but do not know a definitive reference; i.e., this is a
rumor) that Wirth said he made a mistake in the Pascal syntax, and fixed it in
Modula-2. Sure enough, Modula-2 and its descendants have closing bracket
control constructs.
It is another matter whether one prefers "if .. fi", "if .. end", "if .. end
if", or "if .. endif", and I doubt we'll ever reach consensus on that.
Related to BEGIN/END blocks is the argument over whether the ";" that follows
some statements should be a separator or a terminator, the difference being
whether it can occur after the last statement in a list. Similar issues arise
with separator tokens in some forms of case statements (see the Modula-3
syntax for examples). It is possible to allow *both* styles with careful
syntax design; Modula-3 (for one) does that. I tend to favor the more uniform
"terminator" style since, again, it makes additions and deletions simpler. CLU
was actually able to *eliminate* the ";" statement separator/terminator,
through *very* careful syntax design (and maybe it required more than one
token lookahead, too; I don't recall clearly). Anyway, that should be enough
grist for another long running and potentially boring usenet interchange ....
--
J. Eliot B. Moss, Assistant Professor
Department of Computer and Information Science
Lederle Graduate Research Center
University of Massachusetts
Amherst, MA 01003
(413) 545-4206; Moss@cs.umass.edu
--
Send compilers articles to compilers@esegue.segue.boston.ma.us
{spdcc | ima | lotus| world}!esegue. Meta-mail to compilers-request@esegue.compilers-sender@esegue.segue.boston.ma.us (08/10/90)
In article <1990Jul27.034115.8747@esegue.segue.boston.ma.us>, [someone] wrote: > >In the design of CLU we orginally had Algol/Pascal style control construct >syntax, [...] i.e., without closing keyword [...], so that one required a >begin/end pair for a then or else action more than one statement long. >Even with single character abbreviations for begin/end [...] we felt >this was a pain, and while a closing bracket does mean a little more typing, >it [] leads to simpler program modification, ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >especially adding/deleting statements. This was obvious from reflection upon serious use of Algol, Pascal, or PL/I. I wish Wirth had changed things in time for releasing Revised Pascal, but I suspect that he was too taken with the elegance that appears when manipulating tidy little symbols like "B1", "S2", and "V". This apparent elegance disappears when people must maintain serious programs that use meaningful (even with abbreviation) names in complex data structures. Wirth stated in The design of a Pascal compiler. Software--Practice and Experience, v. 1 (1971), p. 309--333 that Pascal was designed, in part, "[t]o gain more insight into the methods of organizing large programs and managing software projects." However, his example programs (used to illustrate the "goodness" of Pascal) were less than 2 dozen lines long in Pascal, and were almost certainly not maintained. >I have also heard (but do not know a definitive reference; i.e., >this is a rumor) that Wirth said he made a mistake in the Pascal syntax, You won't find any such admission in his self-congratulatory paper: Niklaus Wirth: An assessment of the programming language Pascal. IEEE Trans. on Software Engineering, v. SE-1, n. 2 (June 1975), p.192--198. >and fixed it in Modula-2. [...] He didn't wait that long. In N. Wirth: Design and implementation of Modula. Software--Practice and Experience, v. 7 (1977), p. 67--84. ((c) 1976 by N. Wirth), thus Modula"-1", he wrote: As far as the syntax is concerned, Modula deviates from its ancestor Pascal in an essential respect: statement structures consistently follow a single guiding rule. Every structured statement begins with a keyword (uniquely identifying the kind of structure) and ends with a closing symbol. The effect is shown for the while statement Pascal: Modula: while B do S while B do S end while B do begin S1; S2 end while B do S1; S2 end The decisive consideration was that, if a statement is to be inserted in a program, no other symbols (such as _begin_) would have to be inserted (deleted) in addition to the statement itself. The rule that every structured statement had to end with a closing symbol (usually _end_) had, however, the following consequence: Consider the frequent case of a cascaded conditional such as (written in Pascal or Algol 60) if B1 then S1 else if B2 then S2 else ... if Bn then Sn else S This now has to be expressed by the awkward construct if B1 then S1 else if B2 then S2 else ... if Bn then Sn else S end ... end end It is quite natural in this case to introduce a construct that avoids the nesting of structures and eliminates the sequence of _end_ symbols: if B1 then S1 elsif B2 then S2 ... elsif Bn then Sn else S end Note that this represents a genuine, clean solution in contrast to the fixup rule that `multiple ends' may be merged into a single _end_ symbol. I suspect that this is as close as you will find to an admission in print by Wirth that he "made a mistake". The fixup to which he refers is used for "]" in LISP, and for _end_s in PL/I that specified the (optional) alphanumeric label on a structured statement. It was a convenience, but many people would rather have used the labels to verify that the programmer and compiler agreed on the nesting level, i.e., that a diagnostic be issued instead of invoking a fixup rule without notice. >Modula-2 and its descendants have closing bracket control constructs. ^^^^^^^^^^^ As inspired by its immediate *ancestor*. Clay Phipps Intergraph APD: 2400#4 Geng Road, Palo Alto, CA 94303; 415/852-2327 UseNet (Intergraph internal): ingr!apd!phipps UseNet (external): {apple,pyramid,sri-unix}!garth!phipps EcoNet: cphipps -- Send compilers articles to compilers@esegue.segue.boston.ma.us {spdcc | ima | lotus| world}!esegue. Meta-mail to compilers-request@esegue.
ok@goanna.cs.rmit.OZ.AU (Richard A. O'Keefe) (08/14/90)
In article <1990Aug10.035630.764@esegue.segue.boston.ma.us>, writes: > As far as the syntax is concerned, Modula deviates from its ancestor > Pascal in an essential respect: statement structures consistently > follow a single guiding rule. Every structured statement begins with > a keyword (uniquely identifying the kind of structure) and ends > with a closing symbol. The curious thing about this is that Pascal was designed at least in part as a reaction *against* Algol 68, in which the "arms" of structured statements were "serial clauses" and each structured statement had its own kind of terminator. Well, sort of. You could always use ( and ), so begin s1; ...; sn end => ( s1; ...; sn ) if c1 then t1 elif c2 then t2 ... else f fi => ( c1 | t1 |: c2 | t2 ... | f ) case c in s1, s2, ..., sn out f esac => ( c | s1, s2, ..., sn | f ) though you couldn't use (..) for loops. So Modula syntax was a reversion to the Algol 68 approach. Does anyone know where the idea came from in Algol 68? Did Wirth ever say why Pascal didn't imitate _that_ aspect of its distinguished predecessor? -- [It is my impression that Algol68 sprang more or less whole from Van Wijngaarden's (I hope that's right) brain, but I haven't dug into its history in any detail. There is lots of great stuff in Algol68 that is slowly being rediscovered; any student of programming languages should look at it. -John] -- Send compilers articles to compilers@esegue.segue.boston.ma.us {ima | spdcc | world}!esegue. Meta-mail to compilers-request@esegue.