Re: Closing keywords (was Re: Algol, and language design)

ima.ima.isc.com!decvax!decwrl!garth!phipps (Clay Phipps)
Fri, 10 Aug 90 03:56:30 GMT

          From comp.compilers

Related articles
Closing keywords (was Re: Algol, and language design) moss@cs.umass.edu (1990-07-27)
Re: Closing keywords (was Re: Algol, and language design) ima.ima.isc.com!decvax!decwrl!garth!phipps (1990-08-10)
Re: Closing keywords (was Re: Algol, and language design) ok@goanna.cs.rmit.OZ.AU (1990-08-14)
| List of all articles for this month |
Newsgroups: comp.lang.misc,comp.compilers
From: ima.ima.isc.com!decvax!decwrl!garth!phipps (Clay Phipps)
In-Reply-To: <1990Jul27.034115.8747@esegue.segue.boston.ma.us>
Keywords: Pascal, design
Organization: Intergraph APD, in semiarid Palo Alto, CA
References: <25630@cs.yale.edu> <58091@lanl.gov> <1990Jul26.024449.1777@esegue.segue.boston.ma.us>
Date: Fri, 10 Aug 90 03:56:30 GMT

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
--


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.