Xref: utzoo comp.lang.c++:9948 comp.lang.misc:5621 comp.object:1951 Path: utzoo!attcan!uunet!mcsun!ukc!dcl-cs!aber-cs!athene!pcg From: pcg@cs.aber.ac.uk (Piercarlo Grandi) Newsgroups: comp.lang.c++,comp.lang.misc,comp.object Subject: Re: Reading the ARM Message-ID: Date: 13 Oct 90 11:26:22 GMT References: <11216@neptune.inf.ethz.ch> Sender: pcg@aber-cs.UUCP Organization: Coleg Prifysgol Cymru Lines: 148 Nntp-Posting-Host: odin In-reply-to: mneerach@iiic.ethz.ch's message of 11 Oct 90 21:50:37 GMT On 11 Oct 90 21:50:37 GMT, mneerach@iiic.ethz.ch (Matthias Ulrich Neeracher) said: mneerach> In article mneerach> pcg@cs.aber.ac.uk (Piercarlo Grandi) writes: pcg> Yesterday I was on a train trip for twelve hours, so I had the time pcg> for something I had wanted to do for the past few weeks, a cover to pcg> cover uninterrupted read of the Annotated Reference Manual. It took pcg> me only four hours. pcg> I recommend the experience to anybody -- it is simply amazing, in pcg> many ways, especially if you are already familiar with the Algol 68 pcg> Revised Report. Note: part of the amazement is that the two languages are approximately at the same "level", but their defining texts could not be more different. mneerach> I have read the ARM, but not the Algol 68 Revised Report. Incidentally, everybody that wants to understand C++ and algorithmic languages in general *must* read the Revised Report (as anybody that wants to understand OO languages *must* read the Simula 67 Common Base), and possibly also some of the extremely interesting literature on the subject (the Algol Bulletin!). It has had an extremely important influence on many other languages, notably on C and C++; in particular Stroustrup is familiar with the RR and Algol 68 (have a look at the environment in which his Ph.D. thesis was done, just for starters), and many things have been borrowed from it. mneerach> Still, it seems to me there are some essential differences: mneerach> The ARM describes a language that is in its essential parts mneerach> already implemented. There are several independent mneerach> implementations which compile fast and produce efficient code mneerach> (though not always both at the same time :-). Unfortunately, and this is I think one of the spots where Stroustrup has been less of a minimalist than he should have been, certain aspects of the language definition mean that we cannot have efficient and small compilers for C++ (two passes required in many cases, etc...). mneerach> C++ is already in widespread use, and many people use it mneerach> already in more or less the form of the proposed standard. mneerach> This seems to be different from the Algol 68 case. If you want a list of extremely well thought out and often outright brilliant Algol 68 implementations, just ask Charles Lindsey in comp.lang.misc; if you want a long bibliography of papers on how to parse (aaargghhh) or code generate Algol 68 just ask me. Algol 68 technology has been mature for at least the last 10 years. Many, many aspects of this technology are being rediscovered. As to widespread use: in Europe Algol 68 did achieve fairly widespread use. It was also fairly popular in some USA Universities. It has fallen out of favour comparatively recently -- I think the reason is that there are no free or cheap UNIX or DOS compilers for it. Indeed this is nearly the only reason why I do not use it myself anymore. If any of the copyright holders for the Algol68C compiler is listening, please, please, get in touch with the Cambridge Computer Laboratory to agree to release it under the GPL or something like the UCB or Athena copyrights. Please. pcg> If this is where we are going, I am perplexed. Seeing it all before your pcg> eyes in one go makes you ponder. I would give more details, but I think pcg> the experience is ineffable, and has to be relived to be appreciated :-). mneerach> At first, reading the ARM was also somewhat perplexing to me, mneerach> but on closer examination, everything that was mentioned is mneerach> already implemented and feasible implementations were shown. This is one thing I appreciared about the ARM: it is quite informal, and in particular thanks to the commentary and the welath of examples and explanations it can be used an introduction to the language (for people who can read manuals). It is not clearly an introduction to programming, but neither was the original C (Classic or ANSI) or C++ 1.x books. mneerach> The whole ARM shows how much care was taken that no excessive mneerach> strains were put on implementors and programmers. Surely here you must be joking. Three word function pointers? Objects that are really graphs? Automatic synthesis of copy constructors and assignment operators? Pages and pages of rules about conversions on derivation? Tables to explain what are the different rules about different types of member functions? Uhmmm.... mneerach> The attention paid to details doesn't seem to be due to mneerach> "featurism", but to the lot of user feedback, experience, and mneerach> discussion already used in the development of C++. Nobody has ever accused C++ of rampant featuritis -- Stroustrup is after all a minimalist. Not as much as I would like, but still OK. Otherwise he would have designed OO Cobol, not OO C. Note also the obvious and very welcome difference between the ARM and the ANSI C standard. The big problem is that experience is no substitute for insight and hindsight, and of that there is precious little going around as far as advanced OO aspects are concerned -- just consider the reluctance of the CLOS designers to commit themselves to saying 'the right way is this' -- they have provided mechanisms and default policies based on those mechanisms. In C++ one may detect that sometimes there has been yielding to the temptation to get out of difficult problems by arguably unelegant, as noted in the previous paragraph, means, because some solution is better than no solution, even if one suspects that the some solution is not the simplest that could have been used. mneerach> I'd like to see what your vision of C++ is. Your articles seem mneerach> to indicate that you prefer languages like C or maybe Object mneerach> Oberon. Classic C (not ANSI C) is a remarkably fine and elegant balance of simplicity and power, like the original Algol 60 or Algol 68 or other classic works. The design of C++ IMNHO is a bit unsure where one gets out of well known language technology -- especially the hairier OO aspects, like MI, virtuals, etc... (just as say the Algol 68 design is obviously out of its depth in wanton symbol overloading and formats). You may be suprised to learn that my personal preferences go to Scheme, or esoteric things like BETA. Unfortunately, while arguably they could be implemented as SIL/MOHLLs, currently avaialable implementations are not suitable for that use. I wish I could see a Scheme implementation which was not an environment, but one that generated object modules, offered complete control over storage allocation, etc... mneerach> This is ok with me, but don't you agree that if you think C++ mneerach> is a good idea, the path indicated in the ARM is the right way mneerach> to go ? C++ *is* a good idea. And even if it were not that good an idea, it is still the only "real" object oriented SIL/MOHLL. As to the path indicated in the ARM, the complexities are perplexing, all the more so because the ARM is clear enough that they cannot be attributed to the exposition. Let me repeat myself: reread the ARM in one go. A strange feeling of puzzlement will come over you. -- Piercarlo "Peter" Grandi | ARPA: pcg%uk.ac.aber.cs@nsfnet-relay.ac.uk Dept of CS, UCW Aberystwyth | UUCP: ...!mcsun!ukc!aber-cs!pcg Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk