bvs@light.uucp (Bakul Shah) (06/12/88)
In article <10064@tekecs.TEK.COM> Andrew Klossner writes: > ... >There really isn't any "beyond" to Algol 68 since the 1975 Revised >Report. It's a dead language. And that's too bad; while its model of >computation is distant from that of real machines (making it an >inappropriate language for most low level systems programming), it does >an admirable job in its stated domain of algorithmic description, and >is great for applications programming. Actually Algol 68's model quite closely matches real machines and the language can be compiled to generate code as efficient as compiled C; though I doubt there are any modern, optimizing compilers for it. The language is verbose and the its syntax rather od (!) but it can be used quite effectively for systems programming. I recall the CAP operating system (for the Cambridge CAP computer) was written in Algol 68. I wonder how much of C design was influenced by Algol 68 as most of K&R C seems to map almost directly to Algol 68 and where C differs is usually where the compiler's job is simplified. Come to think of it, a major subset of Algol 68 with a new and concise syntax (sort of like C's) can make a very elegant, type safe and well rounded language. -- Bakul Shah <..!{sun,pyramid,ucbvax}!amdcad!light!bvs>
paul@unisoft.UUCP (n) (06/14/88)
In article <1988Jun11.200757.12285@light.uucp> bvs@light.UUCP (Bakul Shah) writes: >In article <10064@tekecs.TEK.COM> Andrew Klossner writes: >> ... >>There really isn't any "beyond" to Algol 68 since the 1975 Revised >>Report. It's a dead language. And that's too bad; while its model of >>computation is distant from that of real machines (making it an > >I wonder how much of C design was influenced by Algol 68 as most >of K&R C seems to map almost directly to Algol 68 and where C >differs is usually where the compiler's job is simplified. Come >to think of it, a major subset of Algol 68 with a new and concise >syntax (sort of like C's) can make a very elegant, type safe and >well rounded language. (speaking as someone who once wrote an Algol 68 compiler ...) in actual fact the language was ahead of its time in terms of compiler technology, nowdays languages are usually designed so that the are relatively easy to generate code for (this is because most language designers are also compiler writers and don't add things they know are going to be excessively inefficient or difficult to implement - smart people). Algol 68 is of a similar complexity to Ada, in fact Ada is one of the few 'modern' languages to include many of the features of Algol 68 (user defined operators etc etc), it was quite entertaining reading the Ada implementation papers a few years ago and comparing them with the Algol 68 implementation papers from 10 years previously (the same things being rediscovered all over again). Probably the main success story from the Algol 68 effort was Pascal, Wirth was one of Algol 68's designers (he was on the committee) and in Pascal he implemented all the things in Algol 68 (plus a few extras) that were easy to implement using the existing technology, the result was a language that flourished .... Paul Campbell PS: Back to the original topic: I spent a lot of my time on my Algol68 compiler trying to figure out how to put it on our Burroughs 6700, my conclusion was that it was not possible to implement any of the pointer code on the 6700 without interpreting everything and making the result too slow to be usefull. One of the main 'problems' with the Burroughs environment is that system security and integrety depends on the security of code files, ie only a privileged program (a compiler) can make a code file and bad code can crash the whole system, this tends to discourage system administrators from letting people develop compilers on their systems ..... needless to say a real C was out of the question .... -- Paul Campbell, UniSoft Corp. 6121 Hollis, Emeryville, Ca E-mail: ..!{ucbvax,hoptoad}!unisoft!paul Nothing here represents the opinions of UniSoft or its employees (except me) "Nuclear war doesn't prove who's Right, just who's Left" (ABC news 10/13/87)
piet@ruuinf.UUCP (Piet van Oostrum) (06/16/88)
In article <1988Jun11.200757.12285@light.uucp> bvs@light.uucp (Bakul Shah) writes: In article <10064@tekecs.TEK.COM> Andrew Klossner writes: > ... >There really isn't any "beyond" to Algol 68 since the 1975 Revised >Report. It's a dead language. And that's too bad; while its model of >computation is distant from that of real machines (making it an >inappropriate language for most low level systems programming), it does >an admirable job in its stated domain of algorithmic description, and >is great for applications programming. Actually Algol 68's model quite closely matches real machines and the language can be compiled to generate code as efficient as compiled C; though I doubt there are any modern, optimizing compilers for it. The language is verbose and the its syntax rather od (!) but it can be used quite effectively for systems programming. I recall the CAP operating system (for the Cambridge CAP computer) was written in Algol 68. I wonder how much of C design was influenced by Algol 68 as most of K&R C seems to map almost directly to Algol 68 and where C differs is usually where the compiler's job is simplified. Come to think of it, a major subset of Algol 68 with a new and concise syntax (sort of like C's) can make a very elegant, type safe and well rounded language. I wrote major parts of both an Algol 68 and an Algol 60 compiler, so I assume I know a bit of the difficulties. Regarding ALGOL 68 and C, I think there are a lot of ideas from Algol 68 in C, but -- as in Pascal -- C left out a lot of the hard things. The syntax of C is much closer to Algol 68 than Pascal. Also some Algol 60 syntax crept into C, e.g. function headers. Now any of the left out features from Algol 68 (e.g. heap variables, dynamic arrays) are not very difficult to add to implement, BUT if you add two or more features at the same time they are going to interact in a terrible manner. The complexity of the resulting compiler is almost exponential to the number of added features. One example: dynamic arrays are easy: Algol 60 had it, see also the discussion on alloca in this newsgroup. Unions are easy: C has them. The combination of dynamic arrays and union however forces you to use the heap, and hence garbage collection. Although I must say I like garbage collection very much, it assumes that you have a perfectly secure language, which C isn't. -- Piet van Oostrum, Dept of Computer Science, University of Utrecht Padualaan 14, P.O. Box 80.089, 3508 TB Utrecht, The Netherlands Telephone: +31-30-531806 UUCP: ...!mcvax!ruuinf!piet
ok@quintus.UUCP (Richard A. O'Keefe) (06/18/88)
In article <492@ruuinf.UUCP> piet@ruuinf.UUCP (Piet van Oostrum) writes: >I wrote major parts of both an Algol 68 and an Algol 60 compiler, so I >assume I know a bit of the difficulties. Regarding ALGOL 68 and C, I think >there are a lot of ideas from Algol 68 in C, but -- as in Pascal -- C left >out a lot of the hard things. The syntax of C is much closer to Algol 68 >than Pascal. I do not understand why people claim a relationship between C and Algol 68. C is BCPL + Pascal types. The only thing that C's "struct"s have in common with Algol 68 is the name, the _semantics_ is Pascalish. C's "unions" are not Algol 68's secure unions (e.g. there is no discrimination case statement) but semantically identical to Pascal's variant records with no tag variable. The set of operations in C is exactly the BCPL set. I think we can explain the function headings by C's descent from BCPL, when types were added to C, it would have been easiest to add new lines to programs than to change old lines. Compare still_legal_c(i, j) LET BCPL_VERSION(I, J) BE { $( return i+j; RESULTIS I+J } $) Even alloca() has a BCPL equivalent (VECTOR N) rather than an Algol 68 one. Just about the only thing in C which I can find in Algol 68 but not in BCPL or Pascal is "long int" and "short int". (Algol 68 uses "long real" and "real", not "double" and "float".) Examples could be multiplied: C's "switch" statement comes from BCPL and has very little in common with Algol 68's "case" statement, C's scoping comes from BCPL, not Algol 68, &c &c &c. It's not that C left anything out from Algol 68, it's that the languages C really is descended from never had them.
jejones@mcrware.UUCP (James Jones) (06/18/88)
In article <125@quintus.UUCP>, ok@quintus.UUCP (Richard A. O'Keefe) writes: > I do not understand why people claim a relationship between C and Algol 68. > C is BCPL + Pascal types. I would think that C coercions were inspired somewhat by Algol 68 (but with considerable sleaze added--Algol 68 wouldn't let you do many of the coercions that C swallows without a peep.) James Jones
bvs@light.uucp (Bakul Shah) (06/19/88)
In article <125@quintus.UUCP> ok@quintus.UUCP (Richard A. O'Keefe) writes: > >I do not understand why people claim a relationship between C and Algol 68. >C is BCPL + Pascal types. ... My mistake. I know C is based on B (based on BCPL (based on CPL]. I didn't say it well but I was wondering if any Algol 68 ideas had influenced C. Some private mail from people who should know seems to indicate there was no direct influence. My apologies for causing any confusion. -- Bakul Shah <..!{sun,ucbvax,pyramid}!amdcad!light!bvs>
isaac@gethen.UUCP (Isaac Rabinovitch) (06/20/88)
In article <1188@unisoft.UUCP>, paul@unisoft.UUCP (n) writes: > Probably the main success story from the Algol 68 effort was Pascal, Wirth > was one of Algol 68's designers (he was on the committee) and in Pascal he > implemented all the things in Algol 68 (plus a few extras) that were easy > to implement using the existing technology, the result was a language that > flourished .... Hm, it's been a long time since I read about this, but I think you have your history wrong. I understand that Wirth thought Algol 68 was a disaster, but was overruled the the rest of the committee. He then went off and did Algol W, Pascal, and Modula, languages which use concepts he couldn't sell to the Algol 68 commitee. Correct me if I have this wrong. I used to love reading the Algol 68 report. All those complicated, interlocking concepts (the version I read arranged the chaptersin a 2-dimensional matrix for easy cross reference) has a lovely, terrible charm. Rather like the Indian Juggernaut ceremony. Isaac Rabinovitch.
anw@nott-cs.UUCP (06/21/88)
> == paul@unisoft.UUCP (Paul Campbell) in <1188@unisoft.UUCP> >> == bvs@light.UUCP (Bakul Shah) in <1988Jun11.200757.12285@light.uucp> >>> == Andrew Klossner in <10064@tekecs.TEK.COM> >>>There really isn't any "beyond" to Algol 68 since the 1975 Revised >>>Report. It's a dead language. And that's too bad; [ ... ] Mostly agreed. Yet there were several good ideas that didn't quite make it into the 1975RR (modals, partial parametrisation, imported/exported variables, etc), but were much discussed in Algol Bulletin, and are only just making it into `modern' languages. And it's not quite as dead as most computing scientists might think. We still have several large applications running on the Univ mainframe; I still use it on our PDP 11/44 [only language available with semaphores, :-(]. Sadly, it will probably die locally if we ever manage to upgrade our hardware. >>I wonder how much of C design was influenced by Algol 68 as most >>of K&R C seems to map almost directly to Algol 68 [...] Well yes, but almost any algorithmic language mostly maps pretty directly to Algol 68. Only K&R could tell you exactly how much K&R were influenced by Algol 68; some things probably were (assignment operators), some things obviously weren't (for statements), and some things ought to have been more so (unification of expressions and statements). >> [...] Come >>to think of it, a major subset of Algol 68 with a new and concise >>syntax (sort of like C's) ... What? The *full* syntax of A68 fits easily as structure diagrams into one side of A4 (the `Watt-Peck-Sintzoff' diagram), or as sort-of BNF rules into a side-and-a-bit (Woodward and Bond rules). Both A68 and its syntax are more concise than C; that was the source of many people's complaints over the years. >> ... can make a very elegant, type safe and >>well rounded language. Yeah! > Probably the main success story from the Algol 68 effort was Pascal, Wirth >was one of Algol 68's designers (he was on the committee) and in Pascal he >implemented all the things in Algol 68 (plus a few extras) that were easy >to implement using the existing technology, the result was a language that >flourished .... Which committee? There were lots. I don't think Wirth (or many of the other `survivors' from the Algol 60 days) had much affinity with A68 as it emerged. The developing schisms, as reported in Algol Bulletin, make highly entertaining reading, and make anything we've seen on the Net about C or Fortran standardisation look like a vicarage tea party. If Wirth had indeed made Pascal an easily implemented A68, we would all be deeply in his debt. Unfortunately, Pascal was a clear step back in language design; and also now a moribund language. Examples of easily implemented A68 features that didn't make it into Pascal: Assignment operators Generalised FOR statement Closures Initialised declarations Declarations "as needed" instead of in a rigid format at top of block Complex numbers Dynamic arrays, and other array features such as UPB SKIP (visible empty statement) etc, etc. IMHO, the Algol thread of language development could be revived, if only someone, somewhere, had a compiler, any compiler, that they were willing to make freely and widely available, eg on the Net. Pascal flourished because compilers and books about it were made easily available. A68 has the books (just about), but not the compilers. -- Andy Walker, Maths Dept., Nott'm Univ., UK. anw@maths.nott.ac.uk
ok@quintus.uucp (Richard A. O'Keefe) (06/21/88)
In article <949@gethen.UUCP> isaac@gethen.UUCP (Isaac Rabinovitch) writes: >I understand that Wirth thought Algol 68 was a >disaster, but was overruled by the rest of the committee. Not the whole of the committee. There was a "Minority Report". Ah, if only the committee had heeded the concerns of the Minority Report; we might have had ADA _years_ earlier (:-). >He then went >off and did Algol W, Pascal, and Modula, languages which use concepts he >couldn't sell to the Algol 68 commitee. Algol W came *before* Algol 68. There are no concepts in Algol W or Pascal that I can think of that aren't in Algol 68, and the main concept in Modula (did you mean Modula or Modula-2? they are quite different) not in Algol 68 is modules. The irony of it all is that Pascal is significantly crippled with respect to Algol W. The essential ideas of Algol 68 were that the whole language should be precisely defined and that all the pieces should fit together smoothly. The basic idea behind Pascal was that it didn't matter how vague the language specification was (it took *years* to clarify) or how many rough edges there were, as long as the CDC Pascal compiler was fast.
smryan@garth.UUCP (Steven Ryan) (06/22/88)
>Algol W came *before* Algol 68. There are no concepts in Algol W or Pascal >that I can think of that aren't in Algol 68, and the main concept in Modula >(did you mean Modula or Modula-2? they are quite different) not in Algol 68 >is modules. The irony of it all is that Pascal is significantly crippled >with respect to Algol W. - A unified loop clause that permits counting and while-conditions. (I understand Oberon dropped the for-statement because so many programs need this combination rather either/or.) - Permits a series in the predicate position. - A safe way to include unsafe predicates: if (guard|unsafepredicate|false)... - Collateral clause which can be structure-display or row-display, or just a nondeterministic construct. - Parallel clause. - A safe union mode (can't diddle the tag field to play silly bit games). - Array bounds are not part of syntax so that formal arrays and actual arrays are easily reconciled. (How long has Pascal struggled with that one?) - Expression language. - Initialised declarations. - Ref ref modes (?). - A mode system that does not require hand waving to cover the difference between variable and value. - Declaration can be near the point of use--no need to introduce a new range for each joined declaration. - Identity declarations. - Operator declarations. - Priority declarations. - Procedures as first class objects. That's all I can think of now right now. Somebody pointed out "Algol does the hard parts and lets the programmer do the easy parts. Pascal does the easy part and makes the programmer do the hard parts." >The essential ideas of Algol 68 were that the whole language should be >precisely defined and that all the pieces should fit together smoothly. >The basic idea behind Pascal was that it didn't matter how vague the >language specification was (it took *years* to clarify) or how many rough >edges there were, as long as the CDC Pascal compiler was fast. And the Pascal method of language definition is unfortunately the accepted and acceptable norm.
bvs@light.uucp (Bakul Shah) (06/25/88)
Seeing Dr. A. N. Walker's article reminds me...
In my opinion, a programming language student should atleast
understand Algol 68 but reading the Revised Report can be
daunting. An excellent introduction to A68 is ``Introductory
Algol 68 Programming'' by D. F. Brailsford and A. N.
Walker (Ellis Horwood Publishers). You may not find it in
bookstores as it was first published in 1979 but a good
library should have it.
-- Bakul Shah <..!{sun,ucbvax,pyramid}!amdcad!light!bvs>isaac@gethen.UUCP (Isaac Rabinovitch) (06/26/88)
In article <130@quintus.UUCP>, ok@quintus.uucp (Richard A. O'Keefe) writes: > In article <949@gethen.UUCP> isaac@gethen.UUCP (Isaac Rabinovitch) writes: > Not the whole of the committee. There was a "Minority Report". > Ah, if only the committee had heeded the concerns of the Minority Report; > we might have had ADA _years_ earlier (:-). Hmm, I'm not too familiar with Ada, and it's been a long time since I used Algol W, but it seems to me that Algol W was a far simpler language. Perhaps the two have crucial features in common, but most of the controversy with Ada seems to be not with the quality of ideas involved but the *quantity*. > > The irony of it all is that Pascal is significantly crippled > with respect to Algol W. Could you expand on that point? I don't remember enough Algol W to understand what you mean, but I do remember enough to be intriqued by your argument. I used to like to like Algol W for its elegance of semantic and syntactic elegance (every block had a value, for example), but everybody else I knew thought that "elegance" made the language kludgy. Anecdotal (and probably not persuasive) counterexample: I once participated in a class project in which we were trying to implement a large program with Algol W running on an IBM 360/40 with half a meg of memory. (Gad, the AT clone I'm using now is more powerful.) Because of intrinsic limitations with Algol W, we tried to switch to Pascal -- which required more memory than we had! So I had to wait a decade to try Pascal. > > The essential ideas of Algol 68 were that the whole language should be > precisely defined and that all the pieces should fit together smoothly. Then they went and came up with the most complicated language definition ever, ruining any hopes of achieving that goal. > The basic idea behind Pascal was that it didn't matter how vague the > language specification was (it took *years* to clarify) or how many rough > edges there were, as long as the CDC Pascal compiler was fast. It's worth remembering that Wirth never meant the language to be *used*. It was supposed to be a language for *thinking* about computing, not implementing systems. I've got early 70s Pascal books that use dialects of Pascal that were never even implemented, and never meant to be. The main reason Pascal is so popular today is the same reason BASIC is: micro programmers were hungry for high-level (relatively) languages, and vendors addressed the marketplace by adapting teaching tools. Thank goodness they never got round to PILOT! Isaac Rabinovitch
smryan@garth.UUCP (Steven Ryan) (06/28/88)
> An excellent introduction to A68
Also, a Practical Guide to Algol 68, by Frank Pagan. Somebody else wrote
a book introducing vW2 grammars and concluding with a formal syntactic
and semantic definition of a small language. North Holland (of course) but
I don't remember authour or title.ok@quintus.uucp (Richard A. O'Keefe) (06/28/88)
In article <961@gethen.UUCP> isaac@gethen.UUCP (Isaac Rabinovitch) writes: >In article <130@quintus.UUCP>, ok@quintus.uucp (Richard A. O'Keefe) writes: >> Ah, if only the committee had heeded the concerns of the Minority Report; >> we might have had ADA _years_ earlier (:-). >Hmm, I'm not too familiar with Ada, and it's been a long time since I >used Algol W, but it seems to me that Algol W was a far simpler language. Just so. The Minority Report claimed that Algol 68 was directed at the wrong issues and didn't provide the tools (modules &c) for building large systems. These were the same concerns that led eventually to ADA, after a wasted decade had shown that Pascal was _not_ the answer. >> The irony of it all is that Pascal is significantly crippled >> with respect to Algol W. >Could you expand on that point? Arrays. Algol W and Algol 68 were just about the last of the languages whose designers thought that the "array" features of a language should be influenced by the needs of "scientific" programmers rather than by the addressing modes of the hardware. (Dijkstra has also resisted the "hardware rules" mentality, but do you see D-arrays going into the next revision of Pascal, or into Fortran 8X?) Even ADA basically just kludges around Pascal's limits. A digression on Algol 68 arrays. You can do things like [1:n, 1:m] REAL a := read_array(n, m); # ... # [] REAL arow = a[i,:], acol = a[:,j]; # ... # ... arow[k] ... # same as a[i,k] # ... acol[k] ... # same as a[k,j] # Why is this useful? After all, a good optimising compiler should notice that a subscript remains constant and evaluate that part of the addressing polynomial just once. The usefulness of the feature is nothing to do with whether it helps the compiler generate better code, though it may, but with that fact that something I didn't write in the code is something I didn't get wrong. It's the same advantage that a[i,j,k] +:= 1 has; because I didn't have to write the LHS twice, I missed one opportunity to make a mistake. >> The essential ideas of Algol 68 were that the whole language should be >> precisely defined and that all the pieces should fit together smoothly. >Then they went and came up with the most complicated language definition >ever, ruining any hopes of achieving that goal. Nope, they didn't ruin any hopes whatsoever of achieving that goal. Not a bit of it! What they ruined was any hope of having many people _realise_ that the goal had been met. If you want to see a complicated language definition, take the ANSI ADA specification and add the INRIA formal definition of ADA (yet another definition which started by inventing a new definition language). I believe that the reason that the moderately complex definition of Algol 68 scared people off but that the ferociously complex definition of ADA hasn't is that people were _shown_ the _whole_ Algol 68 definition, but not so ADA. (Yes, the INRIA definition never made it into the standard. If you read comp.lang.ada you will see that the result is that ADA in practice is about as ill-defined as C.)
piet@ruuinf.UUCP (Piet van Oostrum) (06/29/88)
In article <822@garth.UUCP> smryan@garth.UUCP (Steven Ryan) writes:
Somebody else wrote
a book introducing vW2 grammars and concluding with a formal syntactic
and semantic definition of a small language. North Holland (of course) but
I don't remember authour or title.
Cleaveland, J. Craig & Uzgalis, Robert C.
Grammars for programming languages
New York [etc.] : Elsevier, 1977 * XIV, 154 p. : ill. ; 24 cm
Elsevier computer science library * Programming languages series ; 4
The only relation between Elsevier and 'North Holland' is that they are
located in Amsterdam, which is in the province of North Holland. As far as
I know they have nothing to do with the publisher of that name.
You might also look into:
M. Marcotty and H.F. Ledgard,
A sampler of formal definitions,
Computing Surveys vol 8, no 2 (June 1976)
--
Piet van Oostrum, Dept of Computer Science, University of Utrecht
Padualaan 14, P.O. Box 80.089, 3508 TB Utrecht, The Netherlands
Telephone: +31-30-531806 UUCP: ...!mcvax!ruuinf!pietnick@ccicpg.UUCP (Nick Crossley) (06/30/88)
In article <822@garth.UUCP> smryan@garth.UUCP (Steven Ryan) writes: >Somebody else wrote >a book introducing vW2 grammars and concluding with a formal syntactic >and semantic definition of a small language. North Holland (of course) but >I don't remember authour or title. It is "Grammars for Programming Lnaguages", by J Craig Cleaveland and Robert C Uzgalis, number 4 in the Programming Languages Series published by Elsevier North Holland, 1977. An excellent book for those wanting to see more of what 2-level grammars can do. -- <<< standard disclaimers >>> Nick Crossley, CCI, 9801 Muirlands, Irvine, CA 92718-2521, USA Tel. (714) 458-7282, uucp: ...!uunet!ccicpg!nick