phipps@garth.UUCP (Clay Phipps) (11/24/88)
In article <7774@aw.sei.cmu.edu> firth@bd.sei.cmu.edu (Robert Firth) writes: >...a better test of the language as a piece of design >is the number of key concepts it introduced. And how it fit them together. PL/I introduced or popularized concepts for which it doesn't get much credit, but it seemed that it was less of a hybrid than the result of numerous grafts of features. After all the features were collected (e.g., I/O), PL/I should have undergone a major redesign pass before it was released. Algol-68 features, by contrast, fit together well, at least by the 1971 Revised Report. >This includes ... > a clear and correct definition of coercion I liked the notions of narrowing, widening, and the general applicability of casts, but although Algol-68's notions of coercions and casts were touted as an improvement on PL/I's (I mostly agree), Algol-68 found new areas in which to confuse people. Consider the example presented by Tanenbaum on p. 174 of the July 1976 _Computing Surveys_ (vol. 8, num. 2): begin int I := 0, K := 1; ref int Ptr := I; Ptr := K; Print (I); end [Note that uppercase is used here to begin identifiers; keywords are all lower-case; the paper used fonts to distinguish them.] Execution of the example reportedly printed "0", not "1". The reason has to do with implicit conversions involving "ref" modes (i.e., what many people call "pointers"). See the paper for details. To get the answer that I believe most people would expect: "1", it was necessary to use a "cast": replace "Ptr := K" by "ref int (Ptr) := K". To its credit, Algol-68 provided a nice mechanism: the "cast", for forcing the desired behavior, but to its discredit, it seems to have violated the principle of "least surprise", therefore making it not quite so "clear". Perhaps it grew on you (then again, so could C, FORTRAN, and PL/I). > the "heap" PL/I had a "heap" mechanism as early as when it was called NPL (see Jan. 1965 _CACM_ vol. 8, num. 1, p. 11); it was called "controlled" storage, and required explicit (but simple) pointer manipulation to use in the style of a "heap". PL/I managed it as a stack, although I suspect that few people actually used it that way. No garbage collection was performed; people were expected to manage their own use of storage. I suppose that we can haggle over what constitutes "heapness", but I think that it's the explicit control of lifetime that is important, not features that simplify references to objects on the heap, or clean up after inattentive programmers. I'm sure that some folks will differ with that. > array slicing in a more powerful and more well-founded manner Algol-68 may well have been "more powerful" and "well-founded" in array manipulation than PL/I, but Algol-68 pales in comparison to APL, which merited that glowing description much earlier than Algol-68. APL did have the aggravating inability to use objects whose shape was 1 x 1 x ... x 1 in a scalar context, as I recall from the original Big Blue implementation. >... Algol-68 has an honourable place >even in a history written by the "winners". I certainly agree that Algol-68 deserves far more credit than it receives nowadays. Some of its terms invented for describing the language have become customarily used without the users being aware of the words' origin. Algol-68 also had an interesting notion of "transput": data transfer, known to many by the awkward symbols "I/O". I prefer the Algol-68 term, but it never caught on. I confess that I never had the opportunity to write code in Algol-68; few opportunities for doing so existed in True Blue mainframe shops. By the time I got away from Big Blue shops, Pascal was "in", and Algol-68's van Wijngaarden grammar was used primarily to test the mettle of grad students, not to teach Algol-68. -- [The foregoing may or may not represent the position, if any, of my employer] Clay Phipps {ingr,pyramid,sri-unix!hplabs}!garth!phipps