eric@snark.uu.net (Eric S. Raymond) (12/13/89)
A couple of well-informed comp.arch regulars have suggested that I may
have been a bit too peremptory in dismissing Algol68's influence on later
language development. I will still argue vigorously that the Pascal family
was founded on Algol-60 (consider the relative dates) but I admit that there's
a case for tracing C casts and some aspects of its type system to Algol68.
Would dmr or anyone else with certain knowledge care to comment?
Followups to comp.lang.misc *only* this time...
--
Eric S. Raymond = eric@snark.uu.net (mad mastermind of TMN-Netnews)paul@taniwha.UUCP (Paul Campbell) (12/14/89)
In article <1TmbNv#4mK14j=eric@snark.uu.net> eric@snark.uu.net (Eric S. Raymond) writes: >A couple of well-informed comp.arch regulars have suggested that I may >have been a bit too peremptory in dismissing Algol68's influence on later >language development. I will still argue vigorously that the Pascal family >was founded on Algol-60 (consider the relative dates) but I admit that there's Wirth (the 'father' of Pascal) was a member of the Algol68 committee, after being involved in the design of the language he designed Pascal, he put in many of the Algol68 features that were easy to implement and left out the ones that were hard. Paul -- Paul Campbell UUCP: ..!mtxinu!taniwha!paul AppleLink: CAMPBELL.P "We got a thousand points of light for the homeless man, Got a kinder, gentler, machine gun hand ..." - Neil Young 'Freedom'
pcg@rupert.cs.aber.ac.uk (Piercarlo Grandi) (12/18/89)
In article <1TmbNv#4mK14j=eric@snark.uu.net> eric@snark.uu.net (Eric S. Raymond) writes: A couple of well-informed comp.arch regulars have suggested that I may have been a bit too peremptory in dismissing Algol68's influence on later language development. Would dmr or anyone else with certain knowledge care to comment? In the beginning there was Algol 58, and this was the ancestor of Jovial. Algol 60 was then defined and quite different from Algol 58 (and we lost forever the very important distinction between parallel and serial implementations of arrays of records, as it appears in Jovial). Just after Algol 60 was defined, people started working on its successor, provisionally named Algol X, to be more oriented to non numerical problems, and with a standard io suite and representation. The three major problems with Algol 60 were that it was heavvily oriented towards numerical computations, it lacked any standard hardware representation, and had no standard io library. From Algol 60 people at Trondheim derived first Simula I, then Simula 67, which were OO supersets of Algol 60. Apparently they were not seriosuly considered as candidates for Algol X. History may have been weel different otherwise. In the States PL/1 was defined, with a completely different philosophy (not an algorithmic language, but a programming language). N. Wirth, while in the USA, worked on PL/360 and on Algol W, which had a minor but interesting effect on subsequent history; PL/360 was structured assembler, with an algol like syntax, and the other was an extension of Algol 60 with records and strings etc... In the UK, the CPL language (by Cambridge and London Universities) project was started, and it produced a nice language with operators, valued blocks, and lots of other nifty aspects. To implement it, M. Richards implemented a very small subset of it, called BCPL, which was at the same semantic level as say PL/360, but machine independent, higher level (another such language, byt the way, was Neliac, by Halstead, which was quite good, IMNHO), and with only one data type, the word, and only one type constructor, the array, but had sophisticated control structures and was simple and fast. In Europe, two landmark events happened; Dahl, Dijkstra, Hoare authored "Structured Programming", and Van Wijngaarden proposed a new technology for grammars that could be used to describe context sensitive aspects. After Hoare's paper on data typing in "Structure programming" Wirth designed a language, called Pascal, that implemented a *very small* subset of Hoare's ideas, essentially those that could be implemented with strightforward code generation; such interesting ideas as arrays with other arrays or sets or records as indices were lost, and so on. After Van Wijngaarden, groups in the UK and Holland defined a language, very influenced by CPL, that was described in the new Two Level Grammars invented by Van Wijngaarden. The new language was a very ample extension of Algol 60, and not synctactically compatible with it, and was designed to cover almost any area of programming, with just a small set of basic concepts, that could be combined in many ways. A small war ensued between the Pascal, Wirth, Hoare, Dijkstra camp, and the Van Wijngaarden, Algol 6[68], CPL, camp; Pascal was hailed as a theoretically sound language, Algol 68 fans retorted it was too simple and limited to be adopted as a general purpose international standard. The latter point of view prevailed, and Algol 68 was adopted as an international standard. In 1975 a fully revised language report and a slightly revised Algol 68 language were published. It proved exceptionally difficult to provide a compiler for full Algol 68, because the language syntax was *very* context sensitive, and some language rules were *very* subtle, but eventually it did happen. In the meantime, Pascal, which had been rejected because it was considered too simplistic, achieved fame and popularity because a simple, free implementation was provided. In the meantime BCPL too, much for the same reasons, had become popular, and, thanks to links between Cambridge UK and some USA research centers (Xerox, MIT, Bell Labs), had been adopted in several parts of that country. In particular BCPL was to be the implementation language for the Multics Project, before they decided to switch (with much much pain) to PL/1. Indeed the BCPL compiler on Multics is older than any PL/1 compiler, even if most Multics users don't know there is one. It so happened that certain Bell Labs people were working on Multics, and they were certainly exposed to BCPL, and when Bell Labs got out of Multics, they decided to build a very small OS somewhow inspired to Multics (by the way, it is one of the tragedies of history that many current Unix workstations are far more powerful than the old Multics machines, yet the Unix they run is still far less sophisticated, simple and efficient than Multics was). It also happened that the GE 600 machines used for Multics were also popular in a certain canadian university, that took the BCPL compiler and hacked it a little to create B, a less odd looking version of BCPL (which had quaint British syntax, and also used a very small character set, because of the use of very old printers where it had been developed). It also happened that Bell Labs had as a major service machine a GE 600 machine, and B was installed on it. In the meantime the Unix kernel had been evolving, and the authors felt it was no longer sustainable having it in assembler. The took B as a model, and developed C, a very small (initially) extension to it. They added (initially just a few) different lengths of integers, and symbolic offsets into arrays, turning them into structures. About the same time, several people from cambridge UK happened to visit Bell Labs, among them S. Bourne, one of the authors of the Algol68C (a large subset of algol 68) compiler. This strongly influenced the /bin/sh shell syntax (and its implementation), the adb debugger, and the further evolution of C, which however still retained its fundamental BCPLish flavour. After a while, B. Stroustrup, a Danish guy that had been exposed to Simula 67 at home, and to heavvvvy doses of BCPL and Algol68C at Cambridge UK for his doctorate, joined Bell Labs, and started working on a project called C with Classes, which eventually extended C both with many Algol 68 and Simula 67 features. I will still argue vigorously that the Pascal family was founded on Algol-60 (consider the relative dates) but I admit that there's a case for tracing C casts and some aspects of its type system to Algol68. Well, if you believe what I said above, Pascal was meant as an *alternative* to Algol 60, and as a successor, it had a very distinctly different flavour. Simula 67 and Algol 68 are the true descendants of Algol 60. C has been much influenced by BCPL (of course...) which is a distant relation of Algol 68, by Algol 68 itself, and later on, C++ has been even more heavvily influenced by Algol 68 and Simula 67. C has somewhat more than casts and many aspects of its type system inspired by Algol 68 or Algol 68C. Other interestiong notes: J. Ichbiah, the Ada man, had previously worked a lot on Simula 67, somewhat on Algol 68, and developed an implementation language whose ancestry seems to me clearly derived from Algol 68 or Mary, called LIS, many of which features popped up in Ada. Ada itself also contains a number of ideas taken straight from Algol 68. A german university is now distributing for very cheap a very portable Simula 67 compiler that will also run on home micros... It may still make a comeback! Algol 68 also influenced a lot of research into difficult topics of programming language design and implementation; to this date, papers on Algol 68 implementation make fascinating reading. Frankly, Algol 68 is now all but dead, but if somebody, e.g. Cambridge UK, were to release on the net, e.g. comp.sources.misc, as freeware the Algol68{C} compiler (a *very* fine piece of portable software) and its accessories and libraries and tools etc..., I believe a lot of people in the USA and elsewhere could rediscover its charms, and it could develop into a serious thing. -- Piercarlo "Peter" Grandi | ARPA: pcg%cs.aber.ac.uk@nsfnet-relay.ac.uk Dept of CS, UCW Aberystwyth | UUCP: ...!mcvax!ukc!aber-cs!pcg Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk
ljdickey@water.waterloo.edu (L.J.Dickey) (12/18/89)
In article <1TmbNv#4mK14j=eric@snark.uu.net> eric@snark.uu.net (Eric S. Raymond) writes: | A couple of well-informed comp.arch regulars have suggested that I may | have been a bit too peremptory in dismissing Algol68's influence on later | language development. I will still argue vigorously that the Pascal family | was founded on Algol-60 (consider the relative dates) but I admit that | there's a case for tracing C casts and some aspects of its type system | to Algol68. | I think you will find that C was derived from B (Bell?), which in turn owes a lot to CPL and BCPL from Cambridge. -- L. J. Dickey, Faculty of Mathematics, University of Waterloo. ljdickey@water.UWaterloo.ca ljdickey@water.BITNET ljdickey@water.UUCP ..!uunet!watmath!water!ljdickey ljdickey@water.waterloo.edu
dmr@alice.UUCP (12/18/89)
Grandi's history of languages, <PCG.89Dec17184350@rupert.cs.aber.ac.uk>, seems moderately plausible up until the part I know about directly. Perhaps we have an effect like the one observed after Velikovsky's books: the astronomers agreed that the astronomy was bogus, but some were impressed by his history; some historians thought the opposite. Specifics: Multics was sophisticated, but I would not call it simple and efficient. There was never any plan to write it in BCPL (this would be an anachronism if nothing else). B (the name is an intersection of BCPL and Bonnie, Thompson's wife's name) was done by Thompson at Bell Labs. Waterloo (the Canadian university) got it much later, and made good use of it--to develop Eh and Zed, for example, but this was a branch off the main line. Bourne came to work at Bell Labs after C started, and stayed for several years (rather more than just a visit). He didn't "influence" the Bourne shell and adb, he wrote them. To respond to the topic that started this discussion off: the type structure of C was in fact profoundly influenced by Algol 68. And all the languages mentioned are indeed descendants of Algol 60. Dennis Ritchie dmr@research.att.com att!research!dmr
bs@alice.UUCP (Bjarne Stroustrup) (12/18/89)
Simula was designed and implemented in Oslo, not Trondheim. (maybe you got muddled up with Mary, that came from Trondheim?) Also, I worked extensively with Simula at Cambridge.
amull@Morgan.COM (Andrew P. Mullhaupt) (12/19/89)
In article <PCG.89Dec17184350@rupert.cs.aber.ac.uk>, pcg@rupert.cs.aber.ac.uk (Piercarlo Grandi) writes: > > In article <1TmbNv#4mK14j=eric@snark.uu.net> eric@snark.uu.net > (Eric S. Raymond) writes: > > A couple of well-informed comp.arch regulars have suggested that I may > have been a bit too peremptory in dismissing Algol68's influence on later > language development. > > Would dmr or anyone else with certain knowledge care to comment? > To Eric: I think you may have been a little hasty... | Frankly, Algol 68 is now all but dead, but if somebody, e.g. | Cambridge UK, were to release on the net, e.g. comp.sources.misc, | as freeware the Algol68{C} compiler (a *very* fine piece of | portable software) and its accessories and libraries and tools | etc..., I believe a lot of people in the USA and elsewhere could | rediscover its charms, and it could develop into a serious thing. | -- To Peter: True enough, but people are witnessing a rebirth of interest in another 'dead' language (APL). I would like a copy of that Algol68 from Cambridge if I could have one for UNIX. The most likely use would be to explore in a real environment, (i.e. 'off the blackboard') what some of the data structuring ideas of Algol68 can bring to our in-house language design efforts. Later, Andrew Mullhaupt
rcd@ico.isc.com (Dick Dunn) (12/19/89)
pcg@rupert.cs.aber.ac.uk (Piercarlo Grandi) wrote a long note about the interrelationships of the Algols, Simula, Pascal, etc., but got some of the history turned about. Let's pick up about here... > In Europe, two landmark events happened; Dahl, Dijkstra, Hoare > authored "Structured Programming"... You need to be careful about that one, because the three parts of _Struc- tured_Programming_ have different origins and different real dates. [vanWijngaarden's work] > new technology for grammars that could be used to describe > context sensitive aspects. There are really two aspects to the work here. Remember (or note, if you're fortunate enough not to remember:-) that the original Algol 68 report had the two-level "vW" grammar, but used ordinary prose to describe "context conditions". The revised report (circa 72?) pushed the grammar much further. > After Hoare's paper on data typing in "Structure programming" > Wirth designed a language, called Pascal, that implemented a > *very small* subset of Hoare's ideas... This is a bit backwards. Pascal was first out about 1970; _Structured_ _Programming_ was published after that. However, Hoare's work is properly dated more like '65 (it just took a while to see print in _S_P_), and the work itself certainly laid the basis for Pascal's type structure. I think Hoare and Wirth were working closely at that time. > A small war ensued between the Pascal, Wirth, Hoare, Dijkstra > camp, and the Van Wijngaarden, Algol 6[68], CPL, camp; Pascal > was hailed as a theoretically sound language, Algol 68 fans retorted it > was too simple and limited to be adopted as a general purpose international > standard. Pascal was a result of the war, not the precipitator. There were several candidate language proposals presented to WG2.1, and after very heated dispute (Grandi calls it a "small war"; I would omit "small":-), those favoring a simple language produced a sort of "minority report" and eventually left the group. Pascal followed shortly thereafter. > In the meantime BCPL too, much for the same reasons, had become > popular, and, thanks to links between Cambridge UK and some USA > research centers (Xerox, MIT, Bell Labs), had been adopted in > several parts of that country... I'd say that BCPL had really become significant *before* the Pascal/ Algol 68 flap...although it was certainly alive and well then. [moving to another part...] > About the same time, several people from cambridge UK happened to > visit Bell Labs, among them S. Bourne, one of the authors of the > Algol68C (a large subset of algol 68) compiler. This strongly > influenced the /bin/sh shell syntax (and its implementation),... That's what we know now as the "Bourne shell" - but this appeared circa Version 7, which is very late 70's. The Bourne shell was by no means the first /bin/sh. >...the adb debugger,... Don't forget that there was an Algol 68 implementation for V7 (by Bourne). According to Bourne, adb was developed to help debug that implementation. > I will still argue vigorously that the Pascal family > was founded on Algol-60 (consider the relative dates)... >...Well, if you believe what I said above, Pascal was meant as an > *alternative* to Algol 60, and as a successor, it had a very > distinctly different flavour... Pascal was intended from the start to be a "small" language, and to have a straightforward mapping onto the machine. Given that Pascal was first implemented on CDC 6x00's, and given the grotesque, hideous, abysmal imple- mentation of Algol 60 on that machine, I wonder what part of Wirth's atti- tude to Algol 60 as a real language was formed by latter-day experience with that implementation. > Other interestiong notes: J. Ichbiah, the Ada man, had previously > worked a lot on Simula 67, somewhat on Algol 68, and developed an > implementation language whose ancestry seems to me clearly > derived from Algol 68 or Mary, called LIS, many of which features > popped up in Ada. Ada itself also contains a number of ideas > taken straight from Algol 68... Anyone seriously designing an algorithmic language post-1970 has to have been influenced somehow by Algol 68. I wonder if some of the influences from Algol 68, and more particularly from Mary (a wonderful bit of work) could have come via Mark Rain, who was deeply involved in Mary and at least peripherally involved in both Algol 68 and Green. -- Dick Dunn rcd@ico.isc.com uucp: {ncar,nbires}!ico!rcd (303)449-2870 ...Never offend with style when you can offend with substance.
pcg@aber-cs.UUCP (Piercarlo Grandi) (12/20/89)
In article <10248@alice.UUCP> dmr@alice.UUCP writes:
Specifics: Multics was sophisticated, but I would not call it
simple and efficient.
Well, I beg to differ. Compared to things like VMS, System V, BSD Unix,
etc..., Multics was remarkably small, simple, and fast. I find that a lot of
people tend to forget that Multics run machines on which you would not today
run GNU Emacs. The architecture of Multics was remarkably elegant, and given
the few simple concepts employed and the relatively simple machine
architecture it was also efficient and simpel itself. The use of shared
libraries, memory mapped files, etc... was especially favourable.
Of course, as an example of *really* simple and efficient, I would put
forward V7 Unix (if one is content with its many limits), or MUSS, which is
actually as powerful as Multics, and smaller than Unix V7, and was designed
about the same time as Multics was. I have often thought that MUSS was what
Multics should have been. On the other hand, Multics is still far simpler
and more elegant and efficient than the latter day Unixes. Certainly
architecturally, API-wise, but also I think in implementation, e.g. I think
also in a simple measure of lines of code in the kernel.
There was never any plan to write it in BCPL
(this would be an anachronism if nothing else).
I was not there, and Dennis Ritchie was, but I seem to recollect reading
that the Multics project at MIT was started *before* PL/1 was designed, and
the MIT people, who had good links with Cambridge UK (and some with
Manchester), and were inspired by Atlas and Titan as well as CTSS, had
decided to use BCPL.
It was only after PL/1 was designed and looked like becoming a standard that
(apparently to please GE and BTL, the industrial partners) they decided to
switch to PL/1, and a first, half cooked, compiler for it was written from
scratch, *after* the BCPL had already been done. I sure remember having a
look at the Multics BCPL compiler and seeing that it seemed *very* old (and
nobody knew about it anyhow).
Anybody can tell whether my recollection of having read this is true?
B (the name is an intersection of BCPL and Bonnie, Thompson's wife's
name) was done by Thompson at Bell Labs.
Ooops. A slip. On the other hand, if I remember correctly, either Thompson
or Ritchie did study in a canadian University, and maybe this tripped my
memory.
Bourne came to work at Bell Labs after C started, and stayed for
several years (rather more than just a visit). He didn't "influence"
the Bourne shell and adb, he wrote them.
Yes, yes. I used some understatement, or tongue-in-cheek, here and there
(e.g. describing the Algol 68 Pascal debate as merely a small war...). I was
writing that Bourne's Algol68C experiences influenced very much both the sh
syntax and its source code (in later System Vs it has been de-Algol68fied
though), not to mention the fact that adb had an a68 stack trace command as
well as a c stack trace command ($a and $c respectively, if I remember
correctly).
And all the languages mentioned are indeed descendants of Algol 60.
In an historical sense Pascal is as well, but I would like to maintain my
contention that Pascal's flavour is very different, and I would rather call
it a successor rather then a descendant. It belongs to the "algorithmic"
language family, and comes after Algol 60, but the style is profoundly
different.
--
Piercarlo "Peter" Grandi | ARPA: pcg%cs.aber.ac.uk@nsfnet-relay.ac.uk
Dept of CS, UCW Aberystwyth | UUCP: ...!mcvax!ukc!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.ukpcg@aber-cs.UUCP (Piercarlo Grandi) (12/20/89)
In article <1989Dec18.192301.3863@ico.isc.com> rcd@ico.isc.com (Dick Dunn) writes: > In Europe, two landmark events happened; Dahl, Dijkstra, Hoare > authored "Structured Programming"... You need to be careful about that one, because the three parts of _Struc- tured_Programming_ have different origins and different real dates. Well, they all were presented at the NATO workshops, didn't they? certainly they are utterly different in flavour. The Hoare and the Dahl contributions, about type systems and non nested flow control, have unfortunately been mostly forgotten. Pascal was a result of the war, not the precipitator. There were several candidate language proposals presented to WG2.1, and after very heated dispute (Grandi calls it a "small war"; I would omit "small":-), those favoring a simple language produced a sort of "minority report" and eventually left the group. Pascal followed shortly thereafter. Well, Pascal as we know it today. Let's say I used "Pascal" with some latitude here, to mean the coagulation of the ideas from Hoare's work on typing, and from Wirth's work on PL/360 and Algol W. Indeed Pascal was the answer to Algol 68, and unfortunately more or less buried it. This happened because, I reckon, a free model implementation was readily available, and quickly adopted at many Universities. The Algol 68 guys had painted themselves in a corner, because they had relied on advances in the state of the art in compilers to make Algol 68 implementable and usable. This took quite a few years, not unlike Ada, but for different reasons. I really think that some aspects of Algol 68 (user defined priorities and operator symbols, operators and modes with the same name, excessive overloading of parenthesis, ...) were a very poor tradeoff between language sophistication and cost of compilation, especially as to syntax. At least however Algol 68 *semantics* were carefully designed to be efficiently implementable, and by and large they were. I think that the bits of Algol 68 that went into C++ have been admirably chosen, and Stroustrup has got it more right. The end result is that there are nowadays some excellent (and portable) Algol 68 compilers, like Algol 68C, RSRE, FLACC, and a few others, and some pretty good subset compilers (Manchester for ACK, a British/Canadian one for PDPs, ...). The reader of this newsgroup already knows I wish some were posted to the net... That's what we know now as the "Bourne shell" - but this appeared circa Version 7, which is very late 70's. The Bourne shell was by no means the first /bin/sh. Unfortunately. I always reckoned myself lucky I did serious work on Unix only starting with V7 (can you say "Onyx"? even PDPs were too expensive...). The older shell was almost terrible. I wonder if some of the influences from Algol 68, and more particularly from Mary (a wonderful bit of work) could have come via Mark Rain, who was deeply involved in Mary and at least peripherally involved in both Algol 68 and Green. Well, Mary certainly influenced LIS, judging from the latter's syntax and certain aspects of semantics. I read some papers about Mary in some old Machine Oriented HL Language proceedings, and given that LIS is also described as a MOHLL, I am sure that Ichbiah did his homework and was well aware of Mary. By he way, are these MOHLL conferences still held? They were *very* interesting. -- Piercarlo "Peter" Grandi | ARPA: pcg%cs.aber.ac.uk@nsfnet-relay.ac.uk Dept of CS, UCW Aberystwyth | UUCP: ...!mcvax!ukc!aber-cs!pcg Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk
pcg@aber-cs.UUCP (Piercarlo Grandi) (12/20/89)
In article <10250@alice.UUCP> bs@alice.UUCP (Bjarne Stroustrup) writes:
Simula was designed and implemented in Oslo, not Trondheim.
Yes, yes. Norwegian Computing Center. Great guys.
(maybe you got muddled up with Mary, that came from Trondheim?)
Yes, Mark Rain. He is now in the USA, I seem to remember.
Also, I worked extensively with Simula at Cambridge.
it shows here and there in C++...
--
Piercarlo "Peter" Grandi | ARPA: pcg%cs.aber.ac.uk@nsfnet-relay.ac.uk
Dept of CS, UCW Aberystwyth | UUCP: ...!mcvax!ukc!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.ukdmr@alice.UUCP (12/20/89)
Grandi writes: > It was only after PL/1 was designed and looked like becoming a standard that > (apparently to please GE and BTL, the industrial partners) they decided to > switch to PL/1, and a first, half cooked, compiler for it was written from > scratch, *after* the BCPL had already been done. I sure remember having a > look at the Multics BCPL compiler and seeing that it seemed *very* old (and > nobody knew about it anyhow). He is wrong; just about the first thing I did on coming to Bell Labs was to work on the port of the BCPL compiler to Multics. In fact I wrote the bcpl command, which, just like cc , called in the various compiler phases. (By the time I arrived, Rudd Canaday and Ken Thompson had done the real work of making Martin Richards' 7094 compiler generate GE 645 code instead.) In due course announcement of this compiler appeared in the MSPM as unofficially supported software. The operating system was already a going concern, though not a commercial product, by then (1968). This BCPL compiler is indeed very old; if Grandi has really looked at it, he has looked at characters typed by me, in that year, into a Multics system written in PL/1. The first versions of Multics were written in EPL, for `Early PL/1', a dialect of PL/1 whose compiler was written by Doug McIlroy and Bob Morris. I assure you that the EPL compiler is older than the BCPL compiler, so old that it has vanished except perhaps in someone's file cabinet. In 1969 or so a full PL/1 compiler, courtesy of Freiburghouse etc. of GE was introduced. The person who took a sabbatical at Waterloo was Steve Johnson. He had a real shock. He took B there and planted its seed, but when he came back to Bell Labs, C had appeared, and Alan Snyder had already converted SCJ's yacc program from B into C.... Dennis Ritchie dmr@research.att.com att!research!dmr
seanf@sco.COM (Sean Fagan) (12/20/89)
In article <1517@aber-cs.UUCP> pcg@cs.aber.ac.uk (Piercarlo Grandi) writes: >In article <10248@alice.UUCP> dmr@alice.UUCP writes: > Specifics: Multics was sophisticated, but I would not call it > simple and efficient. Elegant, in what it did, I would add. >Well, I beg to differ. Compared to things like VMS, System V, BSD Unix, >etc..., Multics was remarkably small, simple, and fast. Huh? Multics is/was *huge* (all those lines of PL/I add up, you know 8-))!. Seriously, we're talking hundreds of thousands of lines of code, I believe. The "kernel" was, I suppose, smaller than you would expect, but Mach is tiny comparatively (for the same reasons...). >I find that a lot of >people tend to forget that Multics run machines on which you would not today >run GNU Emacs. GNU Emacs is a poorly-written program. There *was* a version of emacs that ran under Multics, and even had a LISP-interpreter, I believe. As for efficient, I'm going to plug NOS on a CDC Cyber 8-). -- Sean Eric Fagan | "Time has little to do with infinity and jelly donuts." seanf@sco.COM | -- Thomas Magnum (Tom Selleck), _Magnum, P.I._ (408) 458-1422 | Any opinions expressed are my own, not my employers'.
pcg@aber-cs.UUCP (Piercarlo Grandi) (12/20/89)
Well, APL is different, because it has always had loyal commercial
followers, and IBM behind it. APL has never been really dead. Algol 68 is
essentially dead. There are a few users in the UK, NAG may still be
supporting their fine mathematical library with Algol 68 bindings, but
that's it mostly. Anybody still using Neliac? :->
I would like a copy of that Algol68 from Cambridge if I could have one
for UNIX.
Cambridge tend to be fairly liberal with it, at least to Universities (I got
a copy several years ago fairly easily). It is worth having a look at. They
have a very flexible intermediate code generation scheme, that ports easily.
The most likely use would be to explore in a real environment, (i.e.
'off the blackboard') what some of the data structuring ideas of Algol68
can bring to our in-house language design efforts.
Most of them have been borrowed into other languages, so overloading,
operators, etc... you may already know. On the other hand, in Algol 68 they
are beautifully integrated and more general than anywhere else (at times,
too much so). You may, if not already, want to have some hands experience
with Simula 67 as well, because a number of interesting ideas and concepts
from Simula 67 (block prefixing, inner, non nested flow control, class
bodies, inspecting, and a few more recent ones) are not simply there in most
common OO languages. On the other hand Simula 67 has some obvious drawbacks,
mostly because of backwards compatibility with Algol 60, like the forced use
of references for class objects.
Note: Bertrand Meyer, that writes at length about Simula 67 in his
book, seems not to have realized that the forced use of references
is a regrettable hack, not a feature. This is fairly clearly said in
the Simula 67 papers, and too bad that in Eiffel this hack survives,
only worse. By the way, I am working on a paper in which I purport
to show that this hack is the reason why Simula 67 has prefixing,
that was later misnomed inheritance, and that prefixing/inheritance
is superfluous and even negative in a language like C++ that does
not mandate the use of references.
Also, the Algol 68 Revised Report is a model of clarity, simplicity,
conciseness and elegance in language definition, and the use of two level
grammars exemplary, as is the careful choice of terminology. It is well
worth reading on its own sake.
By the way, somebody will disagree with me, but I really think that is true,
especially given the (at times excessive, e.g. coercions) sophistication of
the language. I think that the bad press that Algol 68 got in this area is
because of the original Report, which was not very nice (what about
"gomma"s? :->). The Revised Report is another things entirely.
Compare it with the reference manuals on Ada and C++, which languages are
certainly on the same level of sophistication, and have a good many quirks
as well, and you will see that the Algol 68 RR never fails to make clear
what is the answer to even the most obscure questions (admittedly, you can
formulate much more obscure questions about Ada and C++ than Algol 68).
--
Piercarlo "Peter" Grandi | ARPA: pcg%cs.aber.ac.uk@nsfnet-relay.ac.uk
Dept of CS, UCW Aberystwyth | UUCP: ...!mcvax!ukc!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.ukdavecb@yunexus.UUCP (David Collier-Brown) (12/21/89)
>In article <10248@alice.UUCP> dmr@alice.UUCP writes: > Specifics: Multics was sophisticated, but I would not call it > simple and efficient. pcg@aber-cs.UUCP (Piercarlo Grandi) writes: > Well, I beg to differ. Compared to things like VMS, System V, BSD Unix, > etc..., Multics was remarkably small, simple, and fast. I find that a lot of > people tend to forget that Multics run machines on which you would not today > run GNU Emacs. Alas, BSD 4.3 still isn't as large as Multics, although 4.4 may make it (;-)). As a former Multician (DRBrown.TSDC@HI-Mulics.ARPA) and still Multics bigot, I have to agree with both peter and dmr. It suffered from "sophistication", in that the primitives they picked as being sufficent for the task were large, often complex "objects", usually described properly as subsystems. They were, however, few in number and conceptually simple, which made it easy to reason about once you got past that first horrible case of information overload... As to fast, it varied. The early releases bottlenecked seriously in a number of areas (mostly due to implementation, phew!). Mine was a release 9 on the DPS-8M hardware base and ran like a workstation (:-)). Also, there was no such thing as a small configuration, which meant that the machines usually got loaded with everybody and his brother as soon as they arrived, lest the investment not pay off. Net result: 130 users and fair to poor response. To return to late blooming, I've seen a few of the good ideas quietly resurface (memory mapped segments/files), and the bad ones (like small segments: only 2^18 bytes) pop back up like a handfull of bad pennys. Ah well, it just proves that he who knows not history is doomed to reinvent it. --dave -- David Collier-Brown, | davecb@yunexus, ...!yunexus!davecb or 72 Abitibi Ave., | {toronto area...}lethe!dave Willowdale, Ontario, | Joyce C-B: CANADA. 416-223-8968 | He's so smart he's dumb.
pcg@aber-cs.UUCP (Piercarlo Grandi) (12/22/89)
PL/1, if used carefully, is not that horrible at all, and the Multics guys
had an *excellent* compiler. I read an old MIT TR in which (Saltzer?) there
was a discussion of truly kernelizing Multics, and line counts for the
various system modules were given, and it was not *big*. Notice also that the
linker in Multics is considered a part of the system.
Remember that Unix V7 was about 10-20,000 lines, and that current BSD or AT&T
Unixes run well into the hundred thousands. I would really like to see a
line count, side by side, of SunOS 3 or 4, and System V.3 or 4, and of
Multics. It could be surprising... I doubt *I* would be suprised.
The "kernel" was, I suppose, smaller than you would expect,
but Mach is tiny comparatively (for the same reasons...).
After all Multics used a few elegant concepts thoughtout, and this leads to
simplification in a lot of places, and the standard use of shared libraries
meant a lot of code reuse, which the Multics guys were very keen about.
I also doubt that non kernel parts of Multics are longer than for other
systems. Most of Multics was done by very careful programmers operating under
a well understood set of principles, conventions, ideas, quite unlike Unix.
And again, having high quality shared libraries means *a lot*. I would gladly
throw away many of the Unix tools I have for the equivalent ones under
Multics, which are smaller and more sophisticated. For example, GNU Emacs vs.
Multics EMACS, rn vs. confer, RDMS vs. most every other DB, etc...
I may again be wrong, but I think that the perception of Multics as huge is
really psychological, because the typical Multics kit was huge indeed; I
worked on a many (12, if I remember correctly) processor H6080, for one.
GNU Emacs is a poorly-written program.
Especially as to memory management (editing with the gap method, no
ccompaction of the lisp workspace, ...).
There *was* a version of emacs that ran under Multics, and even had a
LISP-interpreter, I believe.
On the other hand the Multics EMACS, which I had the pleasure to use, by
Greenberg, was *written* in Multics Lisp, which I had the pleasure to use
too. Great thing. Almost conceivable only under Multics. At times I used
Multics Lisp as my shell, an idea that under Unix was done by sombody at Yale.
Once you understand that pipes are bogus and you could say "(sort (ls))"
instead of "ls | sort", something that is only really practical with one
level shared memory architectures, you don't want to go back again. I don't
know it it has been ported, but I think that Icon would also make a fine
Multics shell. Not that the native shell was bad, mind you...
I am sorry about RMS' feelings :-), but I came to believe that Multics EMACS
was *the* proper EMACS, and the original Teco EMACS and the various C
EMACSes floating around just not up to par.
Now RMS or somebody of that ilk could well observe that the model EMACS
should be LMI ZMACS, and I may agree, except that it was overdone and
hackerish. On the other hand interactive programs are really best done in
an interactive language, or at least in a dynamic binding environment.
--
Piercarlo "Peter" Grandi | ARPA: pcg%cs.aber.ac.uk@nsfnet-relay.ac.uk
Dept of CS, UCW Aberystwyth | UUCP: ...!mcvax!ukc!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.ukpcg@aber-cs.UUCP (Piercarlo Grandi) (12/22/89)
>Well, I beg to differ. Compared to things like VMS, System V, BSD Unix, >etc..., Multics was remarkably small, simple, and fast. Huh? Multics is/was *huge* (all those lines of PL/I add up, you know 8-))!. Message-ID: <1549@aber-cs.UUCP> Date: 21 Dec 89 18:11:19 GMT Reply-To: pcg@cs.aber.ac.uk (Piercarlo Grandi) Organization: Dept of CS, UCW Aberystwyth (Disclaimer: my statements are purely personal) Lines: 61 PL/1, if used carefully, is not that horrible at all, and the Multics guys had an *excellent* compiler. I read an old MIT TR in which (Saltzer?) there was a discussion of truly kernelizing Multics, and line counts for the various system modules were given, and it was not *big*. Notice also that the linker in Multics is considered a part of the system. Remember that Unix V7 was about 10-20,000 lines, and that current BSD or AT&T Unixes run well into the hundred thousands. I would really like to see a line count, side by side, of SunOS 3 or 4, and System V.3 or 4, and of Multics. It could be surprising... I doubt *I* would be suprised. The "kernel" was, I suppose, smaller than you would expect, but Mach is tiny comparatively (for the same reasons...). After all Multics used a few elegant concepts thoughtout, and this leads to simplification in a lot of places, and the standard use of shared libraries meant a lot of code reuse, which the Multics guys were very keen about. I also doubt that non kernel parts of Multics are longer than for other systems. Most of Multics was done by very careful programmers operating under a well understood set of principles, conventions, ideas, quite unlike Unix. And again, having high quality shared libraries means *a lot*. I would gladly throw away many of the Unix tools I have for the equivalent ones under Multics, which are smaller and more sophisticated. For example, GNU Emacs vs. Multics EMACS, rn vs. confer, RDMS vs. most every other DB, etc... I may again be wrong, but I think that the perception of Multics as huge is really psychological, because the typical Multics kit was huge indeed; I worked on a many (12, if I remember correctly) processor H6080, for one. GNU Emacs is a poorly-written program. Especially as to memory management (editing with the gap method, no ccompaction of the lisp workspace, ...). There *was* a version of emacs that ran under Multics, and even had a LISP-interpreter, I believe. On the other hand the Multics EMACS, which I had the pleasure to use, by Greenberg, was *written* in Multics Lisp, which I had the pleasure to use too. Great thing. Almost conceivable only under Multics. At times I used Multics Lisp as my shell, an idea that under Unix was done by sombody at Yale. Once you understand that pipes are bogus and you could say "(sort (ls))" instead of "ls | sort", something that is only really practical with one level shared memory architectures, you don't want to go back again. I don't know it it has been ported, but I think that Icon would also make a fine Multics shell. Not that the native shell was bad, mind you... I am sorry about RMS' feelings :-), but I came to believe that Multics EMACS was *the* proper EMACS, and the original Teco EMACS and the various C EMACSes floating around just not up to par. Now RMS or somebody of that ilk could well observe that the model EMACS should be LMI ZMACS, and I may agree, except that it was overdone and hackerish. On the other hand interactive programs are really best done in an interactive language, or at least in a dynamic binding environment. -- Piercarlo "Peter" Grandi | ARPA: pcg%cs.aber.ac.uk@nsfnet-relay.ac.uk Dept of CS, UCW Aberystwyth | UUCP: ...!mcvax!ukc!aber-cs!pcg Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk
firth@sei.cmu.edu (Robert Firth) (12/27/89)
In article <1989Dec18.192301.3863@ico.isc.com> rcd@ico.isc.com (Dick Dunn) writes: >Pascal was a result of the war, not the precipitator. ... >I'd say that BCPL had really become significant *before* the Pascal/ >Algol 68 flap...although it was certainly alive and well then. The documents I think support both these assertions. (1) The publication of record introducing Pascal is Acta Informatica vol 1 pp 35-63, entitled 'The Programming Language Pascal'. The journal most helpfully includes dates of submission as well as dates of publication; it received Wirth's paper on 1970 October 30. (2) The summary to the paper begins thus: A programming language called Pascal is described which was developed on the basis of Algol-60, its range of applicability is considerably increased due to a variety of data structuring facilities. The language was developed by Wirth in the period 1969/70, after he had broken with the Algol-6X group, and in part as an attempt to demonstrate the feasability of his ideas, which, of course, owe a lot to Algol-W and to Hoare's work on data structures. (3) At the time of publication, there was one full Pascal compiler, written in Pascal and executing on the CDC 6600. (This had some bizarre consequences that still plague us, including the line oriented IO, inherited alas by Ada.) (4) By contrast, BCPL had reached the same stage four years earlier, and by 1969 had been ported to the Titan at Cambridge. The first edition of the Cambridge BCPL manual was issued in the same year. The BCPL porting kit was issued in 1971; the date on the accompanying compiler documentation is August 1971. Incidentally, I have a copy of the Cambridge Algol-68C compiler. It is indeed a fine piece of work, and much of it could profitably be studied today.
firth@sei.cmu.edu (Robert Firth) (12/27/89)
In article <1517@aber-cs.UUCP> pcg@cs.aber.ac.uk (Piercarlo Grandi) writes: >I was not there, and Dennis Ritchie was, but I seem to recollect reading >that the Multics project at MIT was started *before* PL/1 was designed, and >the MIT people, who had good links with Cambridge UK (and some with >Manchester), and were inspired by Atlas and Titan as well as CTSS, had >decided to use BCPL. This seems very confused to me. First, 'Atlas' and 'Titan' are the same thing; the machine at Cambridge called 'Titan' was a prototype Atlas II. As far as I know, it's only relevance to the MIT machine is that both used a virtual memory technique derived from the original Manchester design. Moreover, the Titan was programmed largely in machine code; there was a scientific programming language called 'Titan Autocode' made available in 1965 for number crunchers. In contrast to Multics, it had no real user file system; your files were on magnetic tape and your directory was a sheet of paper in your desk drawer on which you wrote down what you had written to which physical block of tape. The Cambridge Time Sharing System came into use only in 1967/68; I remember watching the first remote terminal being installed in 1967. Before that, you had to walk in the side door on Corn Exchange Street and hang your little bag on the hook, containing the paper tape and the job request slip. So it is unlikely to have had much influence on Multics, whose basic design was done by the end of 1966. The 'Multics' project proper was started in October 1965; the second report of the IBM/SHARE committee designing NPL, which contains the greater part of what became PL/I, was issued in June 1964. This should settle the issue of chronological priority; it is of course much harder to decide questions of influence or inspiration.
farber@linc.cis.upenn.edu (David Farber) (12/28/89)
As someone who was there and was part of the descision making process at the beginning of Multics, let me add some info. At the beginning of multics there was the normal problem of what to program it in . We walked through assembler, B, even comtran and fortran. For obvious reasons they were not attractive. I had be in on the begging of NPL (latter PL/1 ) and Doug McIlroy had been on the 3x3 that fortulated NPL initial specs. NPL seemed to be the route to go but there was no compiler for it. Bob Morris and Doug McIlroy thought they could put one togather rapidly so we went with it. In hinesight it was the right path; PL/1 was not a easy language to compile for but there was NO other route. Dave David Farber; Prof. of CIS and EE, U of Penn, Philadelphia, PA 19104-6389 Tele: 215-898-9508(off); 215-274-8292 (home); FAX: 215-898-0587; Cellular: 302-740- 1198 "The fundamental principle of science, the definition almost, is this: the sole test of the validity of any idea is experiment." -- R. P. Feynman
pcg@rupert.cs.aber.ac.uk (Piercarlo Grandi) (12/29/89)
In article <5455@bd.sei.cmu.edu> firth@sei.cmu.edu (Robert Firth) writes:
This seems very confused to me. First, 'Atlas' and 'Titan' are the
same thing; the machine at Cambridge called 'Titan' was a prototype
Atlas II.
The *hardware* was the same (mostly). The OS was, I understand,
quite different. Manchester had their OS, and Cambridge rolled
their own.
[ ... nice reminiscences ...]
The Cambridge Time Sharing System came into use only in 1967/68; I
remember watching the first remote terminal being installed in 1967.
Before that, you had to walk in the side door on Corn Exchange Street
and hang your little bag on the hook, containing the paper tape and
the job request slip. So it is unlikely to have had much influence
on Multics, whose basic design was done by the end of 1966.
This is a funny case of *double* confusion. The Cambridge TSS
that inspired Multics was the one done at MIT, Cambridge, for the
one old IBM machine (that had been modified to support base+limit
"virtual memory"). Multics was then largely inspired by the
virtual memory work done in the UK (minus, unfortunately, the
reverse page map used in ATLAS, which is another great idea whose
time has not yet come, modulo the ROMP...) and by the software
environent of that MIT CTSS, plus a slew of new ideas on
protection, which eventually resurfaced in the capability
bandwagon.
As to Multics, I read once that the sale of GE's computer
interests to Honeywell was the direct cause of Multics being
deemphasized, as the new owners wanted to take time to study
their acquisition and froze all new developments. I have read
that the stop to Multics was what made many major US corporations
(the fat part of the market) that were seriously considering it
as an alternative to IBM (so seriously that IBM hastily did
TSS/370 as a countermove -- BTW, TSS/370 was not that bad or slow
either) stop waiting and choose the IBM 360/370 line and its
horrid OS for good, and consigned posterity to ABENDs.
By the way, a personal note: I have always had this passion for
understanding the history of computer technology. In the
forgotten lateral valleys of such history there are a number of
very interesting things, mostly languages (from Neliac to EL/1),
but also architectures, operating systems, concepts, etc...
Many thanks to those that were there (Ritchie, Firth, Farber...)
for recollecting. I was not there; I am too young for that, and I
have only had the pleasure of skeeing out and reading now
yellowish books and magazines and reports abandoned on some dusty
shelf, and trying out all that I could to get a feel (yes, I
wrote programs in several odd language on several odd systems
just to learn: "Because it was there" :->).
--
Piercarlo "Peter" Grandi | ARPA: pcg%cs.aber.ac.uk@nsfnet-relay.ac.uk
Dept of CS, UCW Aberystwyth | UUCP: ...!mcvax!ukc!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.ukmitchell@community-chest.uucp (George Mitchell) (12/30/89)
In article <18510@netnews.upenn.edu> farber@linc.cis.upenn.edu (David Farber) wrote: >In hinesight it was the right path; PL/1 was not a easy >language to compile for but there was NO other route. Why not ALGOL? /s/ George vmail: 703/883-6029 email: mitchell@community-chest.mitre.org [alt: gmitchel@mitre.arpa] snail: GB Mitchell, MITRE, MS Z676, 7525 Colshire Dr, McLean, VA 22102
pcg@aber-cs.UUCP (Piercarlo Grandi) (01/02/90)
In article <85180@linus.UUCP> gmitchel@mitre.org (George Mitchell) writes: In article <18510@netnews.upenn.edu> farber@linc.cis.upenn.edu (David Farber) wrote: >In hinesight it was the right path; PL/1 was not a easy >language to compile for but there was NO other route. Actually PL/1 is not a bad language. Exception handling is revolting, arithmetic is *CRAZY*, and I/O and tasking a bit less so, syntax at times odd, but for systems programming is not bad at all. Based pointers, areas, reducible procedures (nonstandard), records, UNSPEC(), etc... The only thing I really ever missed was a type naming facility, because LIKE only applies to records (yes, I used to create dummy BASED records as type prototypes...). The macro processor was an incredible beast, better stay out of that. The real problem with PL/1 for system programming is that some of the ridiculous parts of the language, notably exceptions, greatly complicate the procedure call protocol, slowing it down quite a bit, all the funny parts make the compiler slow and bulky, and that in the flagship implementation, IBM's, these problems were especially bad. The IBM PL/I implementations, both optimizing and debugging, are easily the worst around, both as to compiler quality and compiled code quality; the best PL/1s IMNHO are the Multics one (of course!), and the Univac 1100 one. Why not ALGOL? I assume you mean Algol 60; Algol 68 (which is later than Multics, so could not have been used) has been used with great success to write several operating systems. Well, the reasons are obvious: no pointers, no records (BCPL has no records, that's why C exists... :->), no "unsafe" operations, etc... Just not a systems programming language. Let me immediately defuse a counterexample: the "Algol" used to write the Burroughs kernel is not really Algol 60, actually there are two Algols, one for user programs and the other for systems programs; also the hardware is *very* Algol oriented -- Multics is not an Algol like system at all; it is all about dynamic allocation, shared memory, sophisticated pointer mangling. As a fun note, people have been using Fortran for systems programming, e.g. PR1MOS (they switched to a kind of PL/1 later on), and a very good Algol 68 compiler from France. They were both heroic efforts, given the lack of pointers and records. -- Piercarlo "Peter" Grandi | ARPA: pcg%cs.aber.ac.uk@nsfnet-relay.ac.uk Dept of CS, UCW Aberystwyth | UUCP: ...!mcvax!ukc!aber-cs!pcg Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk
beecher@granite.cr.bull.com (Thomas Beecher) (01/03/90)
I'm interested in Grandi's comments about signal/exception processing in PL/I. I've spent slightly more time programming PL/I (on Multics) than C (on UNIX and DOS), so perhaps I'm biased, but... With the possible exception of stack unwinding (cleanup condition) which is hairy under the best of situations, I've found PL/I's signal processing both fully functional and comprehensible. (The difficulties in correctly handling cleanup conditions in Multics PL/I are well documented and well-understood by proficient Multics programmers.) Signal processing is more a function of the operating system than it is of the programming language being used. I can't imagine a tenable argument for SysV's signal processing in C (besides, of course, implementation efficiency, which doesn't hold water for me). I seem to remember a quote from Dennis Ritchie (I think--excuse me, Dennis, if I'm wrong) that suggested that UNIX signals were not designed to convey any information: signals were meant to be either noticed or ignored (sort of like moving faster than the speed of light, eh?). Berkeley signalling sematics are somewhat better. With a well-defined (though perhaps implementation dependent) set of system signals and the ability to define signals in the users' namespace, PL/I offers the programmer complete, determinsitic control over the handling of "exceptional" events. (To those who aren't familiar with Multics, you might also find it interesting to note that signals can be both defined and handled at command level.) I'm not terribly interested in involving myself in a religious (or religiose) argument here, but as for me and my house, I shall long miss PL/I's signalling semantics.
phipps@garth.UUCP (Clay Phipps) (01/04/90)
In article <18510@netnews.upenn.edu>, farber@linc.cis.upenn.edu (David Farber) writes: > >NPL seemed to be the route to go but there was no compiler for it. >Bob Morris and Doug McIlroy thought they could put one togather rapidly >so we went with it. Their estimate was reported by Corbat'o as 6 months. Corbat'o described himself as a "member of the design team" for Multics. >In hinesight it was the right path; >PL/1 was not a easy language to compile for but there was NO other route. Corbat'o reported that "in spite of the dedication of the people involved", reaching the "barely usable" stage actually required 15 months, and "a lot of work went into upgrading it in the next 18 months". "But it works and is useful", he concluded. For more detail than net-bandwidth concerns are likely to allow this thread of discussion to provide on the design and implementation of Multics, readers might be interested in hunting down the 1965 FJCC proceedings. Another source, from which the quotes here were drawn, is the paper F.J. Corbat'o: "PL/I As A Tool For System Programming: Five Years With A Temporary Compiler", _Datamation_ (hide it inside an issue of _CACM_ if you are too embarrassed to risk discovery that you ever read _Datamation_ :-), May 1969. Disclaimer: I wasn't there, so I don't know how representative Corbat'o's paper was of the opinions of members of the Multics project team. Mention of estimated and actual compiler completion times is not intended to denigrate the efforts of the people involved. Deity knows *I'm* not perfect. -- [The foregoing may or may not represent the position, if any, of my employer, ] [ who is identified solely to allow the reader to account for personal biases.] Clay Phipps Intergraph APD: 2400#4 Geng Road, Palo Alto, CA 94303; 415/852-2327 UseNet: {apple,ingr,pyramid,sri-unix}!garth!phipps [^--Please either e-mail replies or allow 16 days for me to see follow-ups :-( ] EcoNet: cphipps