pcg@cs.aber.ac.uk (Piercarlo Grandi) (10/13/90)
On 11 Oct 90 21:50:37 GMT, mneerach@iiic.ethz.ch (Matthias Ulrich
Neeracher) said:
mneerach> In article <PCG.90Oct4141015@odin.cs.aber.ac.uk>
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